[{"category":"blog","content":"Today's developer workflow is increasingly reliant on AI coding agents. Tools like Claude Code sit in your terminal, read your files, run shell commands, make network requests, and write code, all on your behalf. They are fast, capable, and increasingly trusted with real tasks on real machines.\nBut with that trust comes a question worth taking seriously: what exactly is your coding agent doing on your machine?\nToday, we're introducing an experimental project that brings Falco to this new frontier: Prempti.\nAgents are a black box at runtime When a coding agent runs a bash command, writes a file, or reads a configuration, those actions happen inside your user session, with your permissions, in your filesystem, against your credentials. Most developers using these tools have no structured visibility into that activity. You see the agent's chat output, but you don't see what's happening under the hood.\nHere's a simple scenario: you ask your coding agent to refactor a module. It reads your source files. It makes edits. Then, perhaps prompted by a malicious dependency or an unexpected instruction in a file it just parsed, it attempts to read ~/.ssh/known_hosts or write a file to ~/.aws/. Should it be allowed to? Would you even know if it tried?\nThe demo below captures exactly this situation:\nTo run this asciicast without javascript, use asciinema play https://asciinema.org/a/857572.json with Asciinema\nThe agent tried to both read and write to sections it's not allowed to, and both were blocked. The agent itself received a structured message explaining why, and showed that to the user. This is detection and enforcement working together at the tool-call level.\nHow Prempti works Prempti runs as a lightweight user-space service alongside your coding agent. It does not require root, kernel modules, or containers. When your agent makes a tool call such as a file write, a shell command, or a file read, Prempti intercepts it before it executes, evaluates it against Falco rules, and delivers a verdict:\nVerdict What Happens Allow The tool call proceeds normally Deny The tool call is blocked and the agent is told why Ask You are prompted to approve or reject interactively The architecture looks like this:\nPrempti's hook fires before each tool call An interceptor sends the event to Falco via a Unix socket Falco's rule engine evaluates the event against your policies Matching rules produce verdicts (deny / ask / allow) The interceptor delivers the verdict back to the agent Prempti uses Falco's plugin system to define a new event source (coding_agent) with fields purpose-built for this context: tool.name, tool.input_command, tool.file_path, agent.cwd, and so on.\nTwo modes: Monitor and Guardrails Prempti is designed to let you both observe what the agent is doing and align it with your security policy:\nMonitor mode evaluates every tool call against your rules and logs the results, but does not enforce any action. This is what we recommend as a starting point: run it for a few sessions, see what your agent actually touches, and tune your rules before you enable blocking.\nGuardrails mode (the default) fully enforces verdicts as explained above — deny blocks, ask prompts you, allow proceeds.\nYou can switch between modes at any time:\npremptictl mode monitor # observe only premptictl mode guardrails # enforce verdicts premptictl logs # watch live events Writing rules: Familiar territory If you've written Falco rules before, agent security policies will feel very familiar. Here's a rule that blocks piping content directly to a shell interpreter, a classic vector for prompt injection attacks:\n- rule: Deny pipe to shell desc: Block piping content to shell interpreters condition: \u0026gt; tool.name = \u0026#34;Bash\u0026#34; and (tool.input_command contains \u0026#34;| sh\u0026#34; or tool.input_command contains \u0026#34;| bash\u0026#34; or tool.input_command contains \u0026#34;| zsh\u0026#34;) output: \u0026gt; Falco blocked piping to a shell interpreter (%tool.input_command) priority: CRITICAL source: coding_agent tags: [coding_agent_deny] The output field is designed to be LLM-friendly, so that the agent receives it as a structured message it can surface directly to the user. Correlation IDs allow you to trace every event across your logs.\nThe default ruleset ships with policies covering six areas:\nWorking-directory boundary — monitor and ask on file access outside the session's project directory Sensitive paths — deny reads and writes to /etc/, ~/.ssh/, ~/.aws/, cloud credentials, .env files, and similar Sandbox disable — detect attempts to disable the agent's own sandbox configuration Threats — credential access, destructive commands, pipe-to-shell, encoded payloads, exfiltration, IMDS access, reverse shells, and supply-chain installs from known-malicious hosts MCP and skill content — MCP server config poisoning and slash-command file injection Persistence vectors — hook injection, git hooks, package-registry redirects, AI API base-URL overrides, and API keys leaking into env files You can add your own rules to ~/.prempti/rules/user/; they're preserved across upgrades.\nRule authoring with Claude Code The project also includes a Claude Code skill for writing Falco rules for Prempti interactively. You can install it directly from the Prempti plugin marketplace:\n/plugin marketplace add falcosecurity/prempti /plugin install prempti-falco-rules@prempti-skills Then you can ask Claude Code to create rules like:\n\u0026quot;Block the agent from running git push\u0026quot; \u0026quot;Deny any read outside the working directory\u0026quot; \u0026quot;Create a rule that requires confirmation before editing Dockerfiles\u0026quot; The skill guides you through writing the rule, placing it in the right directory, and validating it with Falco. It's a great example of the kind of human-AI collaboration this project is designed to enable: the agent helps you constrain itself.\nLet's be honest about limitations We want to be clear about what this project is and isn't.\nPrempti intercepts tool calls as declared by the agent, not the system calls those tool calls produce. If an agent writes a malicious binary and runs it, Falco sees gcc main.c -o main and ./main, not what ./main does at the OS level. For deep syscall-level visibility on Linux, Falco's kernel instrumentation (eBPF/kmod) remains the right tool.\nPrempti is also not a sandbox. It doesn't prevent a sufficiently determined agent from circumventing the hook mechanism if it can find a path the hook doesn't cover. Think of it as a policy layer at the agent level — a valuable complement to sandboxing and system hardening, not a replacement for them.\nWhat it does provide is visibility and a programmable policy boundary that lives at the most natural enforcement point: the moment the agent decides to act.\nGetting started Download the latest release from the GitHub repository: https://github.com/falcosecurity/prempti/releases\nmacOS:\ninstaller -pkg prempti-\u0026lt;version\u0026gt;-darwin-universal.pkg \\ -target CurrentUserHomeDirectory The installer wizard handles everything. The service starts automatically on login.\nLinux:\ntar xzf prempti-\u0026lt;version\u0026gt;-linux-x86_64.tar.gz cd prempti-\u0026lt;version\u0026gt;-linux-x86_64 bash install.sh Windows:\nmsiexec /i prempti-\u0026lt;version\u0026gt;-windows-\u0026lt;arch\u0026gt;.msi Verify your setup:\npremptictl status premptictl hook status Explore together with us Runtime security for AI coding agents is genuinely new territory. The threat models are still being defined. The right default policies are still being discovered. We believe our community of developers, security engineers, and the people running these agents day to day are the ones who will figure out what good looks like here. If you've used Prempti, we'd love to hear what you found:\nWhat rules have you written? What did you catch? What agents or platforms do you need support for? What didn't work as expected? Open an issue, start a discussion, or come chat with us in the Falco Slack. Every piece of feedback shapes what this project becomes.\nPrempti is released under the Apache License 2.0. Currently supports Claude Code on Linux (x86_64, aarch64), macOS (Apple Silicon, Intel), and Windows (x86_64, ARM64). Codex integration is on the roadmap.\n","summary":"","tags":["Prempti","AI Coding Agents","Falco"],"title":"Introducing Prempti: Falco meets AI coding agents","url":"https://v0-43--falcosecurity.netlify.app/blog/introducing-prempti/"},{"category":"blog","content":"Dear Falco Community, today we are excited to announce the release of Falco Operator 0.2.0, the first production-ready release of the Kubernetes operator for Falco!\nSince the technical preview announced with Falco 0.41.0, we have been working hard to make the operator robust, extensible, and ready for real-world environments. This release brings a redesigned API, a new Component controller for managing the Falco ecosystem, new artifact management capabilities, enhanced observability, and a significantly improved operational model, all grounded in Kubernetes-native patterns.\nWe merged 58 commits since v0.1.1, delivering major new features, 10 bug fixes, and comprehensive architectural improvements. Thank you to all our contributors and the community for your feedback along the way!\nGoing forward, the Falco Operator is the recommended way to deploy and manage Falco on Kubernetes. While the existing Helm chart remains fully supported, we plan to transition to the operator as the standard deployment method. More details on the transition timeline will follow in a future announcement.\nTo learn everything about the changes, read on!\nWhat's new? TL;DR Key features:\nEcosystem components - deploy Falcosidekick, Falcosidekick UI, and k8s-metacollector as managed components ConfigMap support for rules and configuration, alongside OCI artifacts and inline definitions Structured API types for inline rules and configuration - YAML objects instead of strings Redesigned OCI artifact API with separate image and registry configuration Reference tracking with finalizers to prevent accidental deletion of Secrets and ConfigMaps Enhanced observability with Kubernetes events and status conditions across all controllers Update strategy support for DaemonSet and Deployment modes Server-Side Apply migration for safer, conflict-free reconciliation Key fixes:\nPlugin initConfig now supports nested configuration objects RBAC compatibility with Kubernetes 1.32+ Spurious update prevention via managed fields comparison Correct event recording with node-level attribution This release comes with breaking changes that require updating your existing custom resources before upgrading. Please read the migration guide carefully before proceeding.\nThe road to production readiness When we introduced the Falco Operator as a technical preview in Falco 0.41.0, the vision was clear: provide a Kubernetes-native way to deploy and manage Falco that goes beyond what Helm charts and static manifests can offer. Since then, every aspect of the operator has been refined.\nThe reconciliation logic now uses Server-Side Apply for conflict-free updates. Status conditions follow Kubernetes conventions (Programmed, ResolvedRefs, Available, Reconciled) so that standard tooling and dashboards can monitor operator health out of the box. Finalizers protect referenced resources from accidental deletion. And the new Component controller lays the groundwork for managing the entire Falco ecosystem from a single operator.\nVersion 0.2.0 is the result of this effort, a release we are confident in for production environments.\nMajor features and improvements Ecosystem components The new Component custom resource (instance.falcosecurity.dev/v1alpha1) enables the operator to deploy and manage the full Falco ecosystem from a single control plane. Three component types are supported:\nType Component What it does metacollector k8s-metacollector Centralized Kubernetes metadata for Falco instances falcosidekick Falcosidekick Fan-out daemon - routes Falco events to 70+ integrations (Slack, Elasticsearch, S3, Kafka, and more) falcosidekick-ui Falcosidekick UI Web dashboard for real-time event visualization Deploying Falcosidekick is as simple as:\napiVersion: instance.falcosecurity.dev/v1alpha1 kind: Component metadata: name: sidekick spec: component: type: falcosidekick replicas: 2 The operator handles the Deployment, Service, ServiceAccount, and RBAC automatically. Each component type ships with production-ready defaults (health probes, security context, resource profiles) that can be fully customized via podTemplateSpec.\nFor Falcosidekick UI, note that an external Redis instance is required. If Redis is not available, the pod stays in Init:0/1 state, the built-in wait-redis init container blocks until Redis is reachable. See the component documentation for setup examples including a bundled Redis StatefulSet.\nAs part of this work, the internal controller structure was reorganized under controllers/instance/ with shared reconciliation logic extracted into reusable packages, improving maintainability and consistency across all instance-level controllers.\nConfigMap support for rules and configuration Rulesfile and Config resources can now source their content from Kubernetes ConfigMaps, in addition to OCI artifacts and inline definitions. This provides a familiar, Git-friendly workflow for teams that manage configuration through standard Kubernetes tooling.\nRulesfile from a ConfigMap:\napiVersion: artifact.falcosecurity.dev/v1alpha1 kind: Rulesfile metadata: name: custom-rules spec: configMapRef: name: my-rules-configmap priority: 50 Config from a ConfigMap:\napiVersion: artifact.falcosecurity.dev/v1alpha1 kind: Config metadata: name: custom-config spec: configMapRef: name: my-config-configmap priority: 50 The referenced ConfigMap must contain the content under a key named rules.yaml (for Rulesfile) or config.yaml (for Config). All three sources (OCI, inline, and ConfigMap) can be combined in a single resource when needed.\nStructured API types The inlineRules field in the Rulesfile CRD and the config field in the Config CRD are now structured YAML objects instead of plain strings. This enables proper validation, better editor support, and eliminates the need for YAML-in-YAML escaping.\nBefore (v0.1.x):\nspec: config: |- engine: kind: modern_ebpf After (v0.2.0):\nspec: config: engine: kind: modern_ebpf The same applies to inlineRules: rules are now defined as structured YAML lists rather than pipe-literal strings.\nRedesigned OCI artifact API The OCI artifact reference model has been completely redesigned for clarity and extensibility. The previous flat reference and pullSecret fields are replaced with a structured image and registry model.\nBefore (v0.1.x):\nspec: ociArtifact: reference: ghcr.io/falcosecurity/rules/falco-rules:latest pullSecret: secretName: my-secret After (v0.2.0):\nspec: ociArtifact: image: repository: falcosecurity/rules/falco-rules tag: latest registry: name: ghcr.io auth: secretRef: name: my-secret This separation makes the API more explicit and enables per-registry TLS configuration, plain HTTP support, and a consistent credential model. See the migration guide for details on updating your resources.\nReference tracking with finalizers The operator now adds finalizers to Secrets and ConfigMaps that are referenced by artifact resources. This prevents accidental deletion of credentials or configuration data that would break Falco deployments. When a referenced resource is deleted, the operator blocks the deletion until all referencing artifacts are updated or removed.\nEnhanced observability All controllers now emit Kubernetes events for significant operations: artifact creation, updates, removals, and priority changes. Events include the node name for artifact controllers, making it straightforward to trace which operations happened on which nodes.\nStatus conditions have been overhauled to follow Kubernetes conventions:\nArtifact resources report Programmed (whether the artifact is successfully applied) and ResolvedRefs (whether referenced ConfigMaps/Secrets exist) Falco instances report Reconciled and Available All artifact CRDs now include printcolumns for readable kubectl get output Update strategy support The Falco CRD now accepts update strategy configuration for both deployment modes:\n# DaemonSet mode spec: type: DaemonSet updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 # Deployment mode spec: type: Deployment strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 Server-Side Apply Under the hood, the operator has migrated from the dry-run/update pattern to Server-Side Apply (SSA) for all reconciliation operations. This brings:\nConflict detection: concurrent modifications to managed fields are detected and reported Ownership tracking: the operator only manages fields it owns, leaving user-applied changes intact Reduced spurious updates: managed fields comparison prevents unnecessary API calls Breaking changes ⚠️ Version 0.2.0 includes several API breaking changes. All existing custom resources must be updated before upgrading. A detailed migration guide is available in the repository documentation.\nSummary of breaking changes Change Impact Migration ociArtifact.reference replaced by ociArtifact.image + ociArtifact.registry All Rulesfile and Plugin CRs using OCI artifacts Split the reference into image.repository, image.tag, and registry.name ociArtifact.pullSecret replaced by ociArtifact.registry.auth.secretRef CRs with private registry credentials Update the credential reference path Config spec.config changed from string to structured YAML All Config CRs Remove the |- pipe literal, write YAML directly Rulesfile spec.inlineRules changed from string to structured YAML Rulesfile CRs with inline rules Remove the |- pipe literal, write YAML directly Plugin spec.config.initConfig changed from map[string]string to JSON Plugin CRs with init config Re-apply CRD; flat maps still validate Falco resource shortName changed from prom to falco Scripts using kubectl get prom Use kubectl get falco instead Condition types renamed (ConditionReconciled → Reconciled, ConditionAvailable → Available) Monitoring tools filtering on condition types Update condition type filters kubectl get column output changed for all CRDs Dashboard parsing or scripts Update parsers to match new column names RBAC permissions expanded Security-sensitive environments Review the updated ClusterRole After upgrading, re-apply all CRDs and update your custom resources following the migration guide. The operator will reconcile the new format automatically.\nA Helm chart is on its way We are currently developing a Helm chart for installing the Falco Operator itself, which will simplify deployment and configuration of the operator in production environments. Stay tuned for the announcement.\nMeet us at KubeCon We will be talking about the Falco Operator during the maintainer track at the upcoming KubeCon. If you are interested in learning more, asking questions, or sharing feedback, come find us at the CNCF Falco kiosk, we would love to chat!\nTry it out Install the operator:\nVERSION=latest if [ \u0026#34;$VERSION\u0026#34; = \u0026#34;latest\u0026#34; ]; then kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/latest/download/install.yaml else kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/download/${VERSION}/install.yaml fi Then choose how you want to get started:\nFull stack quickstart Deploy the entire Falco ecosystem in the falco namespace with one command:\nVERSION=latest if [ \u0026#34;$VERSION\u0026#34; = \u0026#34;latest\u0026#34; ]; then kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/latest/download/quickstart.yaml else kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/download/${VERSION}/quickstart.yaml fi This deploys Falco, container and k8smeta plugins, detection rules, Falcosidekick, Falcosidekick UI with Redis, and k8s-metacollector - all pre-wired.\nVerify:\nkubectl get falco,plugins,rulesfiles,configs,components -n falco kubectl get pods -n falco Step by step Deploy Falco:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: instance.falcosecurity.dev/v1alpha1 kind: Falco metadata: name: falco spec: {} EOF Add the container plugin (required by the official rules for container metadata fields):\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: artifact.falcosecurity.dev/v1alpha1 kind: Plugin metadata: name: container spec: ociArtifact: image: repository: falcosecurity/plugins/plugin/container tag: latest registry: name: ghcr.io EOF And add detection rules:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: artifact.falcosecurity.dev/v1alpha1 kind: Rulesfile metadata: name: falco-rules spec: ociArtifact: image: repository: falcosecurity/rules/falco-rules tag: latest registry: name: ghcr.io priority: 50 EOF Optionally, add Falcosidekick to route events to your favorite integrations:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: instance.falcosecurity.dev/v1alpha1 kind: Component metadata: name: sidekick spec: component: type: falcosidekick replicas: 2 EOF For the complete documentation, including the CRD reference, configuration options, and architecture overview, visit the Falco Operator repository and the operator setup guide.\nStay connected Join us on social media and in our community calls! It's always great to have new members in the community, and we're looking forward to hearing your feedback and ideas.\nYou can find all the most up-to-date information at https://falco.org/community/.\n","summary":"","tags":["Falco Operator","Release"],"title":"Introducing Falco Operator 0.2.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-operator-0-2-0/"},{"category":"blog","content":"We're excited to share that the Falco community will be at KubeCon + CloudNativeCon Europe 2026 in Amsterdam! Whether you're a long-time contributor, a curious user, or just want to say hi, we'd love to see you there.\nFalco is celebrating 10 years of development and adoption, and we are on the lookout for people who would like to say Happy Birthday to the project or share their best Falco story. Libby Schulze and I will be on the event floor with mic and camera to capture some amazing moments and memories from Falco's 10 years. So bring your best story, and we'll see you at the Falco booth!\nSneak peek Psst... we have something really cool brewing that we will show at the Falco booth. You, our amazing reader, is the first to hear about this. It's a way to run Falco locally on your development machine, and make sure your AI coding agents are following new rules that are being defined. We'd love to get your feedback on this as we're currently building it!\nHere’s where you can find us in Amsterdam and everything we have lined up:\nProject lightning talk Forensics With Falco\nSpeaker: Gerald Combs, Maintainer\nWhen: Monday, March 23, 2026 — 10:27 to 10:32 CET\nWhere: Elicium 2\nFalco has recently expanded its capabilities with capture recording, opening the door to seamless integration with forensic analysis tools like Stratoshark. In this lightning talk, Gerald will walk through how the two tools work together to provide deep visibility into container and system activity. He will demonstrate how captured event data can accelerate investigations and discuss key considerations for safely and efficiently deploying these features in production environments.\nSysdig-led workshop Hands-On Cloud Native Security Workshop\nWhen: Monday, March 23 — 2:00–4:00 PM CET\nRun Atomic Red Team™ tests, then step into the Blue Team role to detect threats and create custom Falco™ detection rules in this hands‑on 90‑minute keyboard workshop.\nConference talk In Falco's Nest: The Evolution of Cloud Native Runtime Security\nSpeakers: Iacopo Rozzo (Sysdig), Aldo Lacuku (Kong Inc.)\nWhen: Tuesday, March 24, 2026 — 12:00 to 12:30 CET\nWhere: G102–103\nFalco, the Cloud Native Runtime Security project, is constantly evolving to meet the demands of modern cloud environments. This maintainer track session, led by the Falco maintainers, will dive deep into the latest advancements and the strategic direction of the project. We will focus on two major areas of growth: the introduction of the new Falco Operator and the new features that enhance Falco's performance and reliability.\nThe new Falco Operator simplifies the deployment, configuration, and management of Falco across Kubernetes clusters, making it easier than ever for users to secure their runtime environments at scale.\nFurthermore, we will explore the most significant new features integrated into Falco. This includes performance optimizations for high-throughput environments. The session will also touch upon community contributions, ecosystem integrations, and the roadmap for the upcoming release.\nBooth demo Pivoting from detection to investigation with Falco and Stratoshark\nSpeaker: Gerald Combs\nWhen: Tuesday, March 24, 2026 — 15:45 CET\nWhere: Sysdig Booth #671\nSee how to move from “we detected something” to “here’s what happened” using Falco and Stratoshark. Stop by the Sysdig booth and say hello!\nThank you! We couldn’t do this without you all in our community - the contributors, users, and everyone who shows up at events. If you’re in Amsterdam, come find us at the talks, the workshop, or the booth. We’d love to meet you and hear how you’re using Falco.\nSee you there! 🐦\n","summary":"","tags":["Falco","Community","KubeCon","Kubernetes","Live Event"],"title":"Falco at KubeCon Europe 2026 — See You in Amsterdam! 🐦","url":"https://v0-43--falcosecurity.netlify.app/blog/kubecon-eu-2026/"},{"category":"blog","content":"New year, new opportunities!\nAs we spread our wings and glide into 2026, we want to make sure this community is one you’re proud (and excited!) to be a part of. Falco has always been more than just a project: it’s a flock of builders, defenders, contributors, question-askers, doc-writers, rule-tuners, and runtime security enthusiasts.\nAnd now we want to hear from you.\nWe’ve put together a quick community survey (5 minutes or less!) to better understand:\nHow connected you feel to the community What you love about being a part of it What could be better What you’d like to see us focus on this year What resources would make your life easier How you’re using Falco and what tools you integrate it with Your feedback directly shapes our focus on what we build, improve, prioritize, and invest in this year - from documentation and content to events, integrations, and contributor experience. A report detailing the responses will be shared at the same time as KubeCon Europe 2026.\nWhether you’re building, using, learning, or just keeping an eye on things, your voice matters.\n👉 Take the survey here Thanks for being part of the flock. We couldn’t do this without you and we’re excited to build 2026 together!\n","summary":"","tags":["Falco","Community"],"title":"Hey Falco Flock! 🐦 Let's Soar Into 2026","url":"https://v0-43--falcosecurity.netlify.app/blog/soar-into-2026/"},{"category":"blog","content":"Dear Falco Community, we are happy to announce the release of Falco 0.43.0 today!\nThis is a stabilization release that consolidates the changes introduced in 0.42.0, including the drop-enter initiative and the capture recording feature. It also introduces several deprecations to improve maintainability and fixes minor issues across falcoctl, plugins, and libs.\nDuring this release cycle, we merged:\n31 PRs on Falco, including 11 release note-worthy changes 48 PRs on Falco libs, including 17 release note-worthy changes 8 PRs on Falco drivers, including 3 release note-worthy changes We upgraded libs to version 0.23.1 and drivers to 9.1.0+driver. Thank you to our maintainers and contributors. This would not have been possible without your support and dedication!\nTo learn everything about the changes, read on!\nWhat's new? TL;DR Deprecations GPG key rotation Container plugin improvements Falcoctl tweaks and improvements Key fixes:\nevt.arg.filename field reintroduction Falcoctl signature verification fixes overflow and NULL pointer dereferences fixes for the container plugin, shipped with plugins/container/0.6.1 race condition fix for the k8smeta plugin, shipped with plugins/k8smeta/0.4.1 This release also comes with breaking changes that you should be aware of before upgrading.\nLatest updates Deprecations In Falco 0.43.0, we are announcing the deprecation of three significant components to streamline the project, reduce maintenance burden, and focus on modern, more efficient alternatives. All these components are stable, and considering that the deprecation is first enforced in this version, they could be removed at any future version starting from 0.44.0.\nLegacy eBPF probe deprecation The \u0026quot;legacy\u0026quot; eBPF probe (configured via engine.kind=ebpf) was the original eBPF implementation in Falco. It required compiling a specific probe for each kernel version, often necessitating the dynamic usage of the falco-driver-loader or pre-built drivers. The Modern eBPF probe (engine.kind=modern_ebpf), which leverages CO-RE (Compile Once – Run Everywhere), has reached maturity and feature parity. It offers superior stability, portability (no need to compile drivers on the fly), flexibility and performance. Maintaining two eBPF drivers splits engineering effort and complicates the codebase. Users currently using the legacy eBPF probe are strongly encouraged to switch to the Modern eBPF probe by setting engine.kind=modern_ebpf in their falco.yaml, or to engine.kind=kmod if the used kernel doesn't provide support for the modern eBPF probe.\nSee the relevant section of the deprecation proposal for the detailed motivation behind the deprecation.\ngVisor deprecation The gVisor engine is a dedicated, internal C++ implementation designed to monitor system calls from gVisor sandboxes leveraging events coming from gVisor itself through gRPC. There is evidence that this engine is little used. Moreover, gVisor doesn't provide all information required to build all supported event types, indeed resulting in a system call source not completely equivalent to the ones provided by drivers. Finally, it requires libs being dependent on protobuf, this latter introducing a non-negligible build time overhead and maintainability burden.\nSee the relevant section of the deprecation proposal for the detailed motivation behind the deprecation.\ngRPC output and server deprecation The gRPC output was implemented to allow external consumers to subscribe to a stream of Falco security alerts over a gRPC connection. It was notably utilized by tools like the event-generator (in test mode) and custom integrations requiring a streaming API for alerts. The gRPC output and the gRPC server embedded in Falco add substantial complexity to the core codebase, including dependencies on specific protobuf and gRPC framework versions in Falco and libs. Over time, it has become clear that the community prefers standard, widespread integration patterns for alert consumption - primarily HTTP and the ecosystem enabled by Falcosidekick. Users consuming alerts via gRPC should migrate to the HTTP output or use Falcosidekick to forward events to their destination of choice.\nSee the relevant section of the deprecation proposal for the detailed motivation behind the deprecation.\nGPG key rotation In anticipation of the previous GPG key's expiration in January 2026, we have rotated the GPG key used to sign the official RPM and DEB packages. Pre-existing Falco installations (installed via apt or yum before the rotation) must manually import the new GPG key. Failure to do so may result in errors during package updates or verification failures. Please follow the \u0026quot;Trust the falcosecurity GPG key\u0026quot; step in the official documentation for your package manager:\napt (Debian/Ubuntu): Install with apt yum/dnf (CentOS/RHEL/Fedora): Install with yum Notice that new installations following the current documentation will automatically receive the updated key bundle and do not require additional steps.\nFor more details see [TRACKING] [deadline 2026-01-17] Rotate public GPG key for RPM/DEB package signing.\nContainer plugin improvements The container plugin, which extracts metadata from container runtimes to enrich Falco events, includes important updates in version 0.6.1 to enhance its API capabilities and performance. This release exposes container.id, container.image, container.name, and container.type through the table API and adds comprehensive logging across all engines, while also preventing allocations by extensively using zero-allocation tools offered by the C++ (like std::string_view) and avoiding reflex matcher allocations during resolve operations.\nFalcoctl tweaks and improvements follow polling interval increase to 1 week About three years ago, we started distributing Falco artifacts (rules files and plugins) via ghcr.io, and later added automatic rule updates in falcoctl with a 6h check interval. With years of data now, it’s clear we don’t need checks that frequent: our rule updates happen far less often. Moreover, due to the growth of Falco adoption, these frequent checks are now hitting ghcr.io rate limit. These two reasons drove the decision to increase the artifact follow interval from 6h to 1 week.\nFor more details see chore(scripts/falcoctl): increase follow interval to 1 week and Falco's Helm chart changelog.\nDependency resolution improvements The artifact installation logic has been reworked to handle dependencies and references correctly. Previously, dependencies could be duplicated or incorrectly resolved, and signature verification was skipped for full registry references. Now dependencies are properly deduplicated, all refs are correctly resolved, and signatures are verified for all resolved dependencies, not just the top-level artifacts. This provides end-to-end verification of the entire dependency chain.\nFor more details see Inefficient deduplication logic and incorrect input handling for dependency resolution\nSupport for cosign v3 Falcoctl now supports Cosign v3 bundle format for signature verification. This is the new standard for signing OCI artifacts, replacing the legacy .sig tag format.\nWhat this means for you:\nArtifacts signed with cosign v3 are now fully supported Backward compatibility with cosign v2 signatures is maintained For more details see feat: Upgrade to Cosign v3 with Bundle Format\nKey fixes evt.arg.filename field reintroduction As part of the recent \u0026quot;drop enter\u0026quot; optimization initiative (which removed enter events for most syscalls to improve performance), the filename argument - historically available only in the enter event for execve and execveat - was inadvertently made unavailable. This caused a regression where specific context, such as the exact path provided to the syscall (e.g., a symlink path versus the resolved binary path), was lost in the remaining exit event.\nIn Falco 0.43.0 (via libs 0.23.0), this has been fixed. The filename argument is now correctly populated in the exit events for these syscalls. Users can once again access this data using the evt.arg.filename field in their rules, ensuring that the critical execution context is preserved without needing the deprecated enter events.\nFor more details see Missing \u0026quot;filename\u0026quot; argument to execve syscall in libscap 0.22.x.\nFalcoctl signature verification fixes Signature verification fix for full reference artifacts Fixed an issue where signature verification was skipped for artifacts specified with a full registry reference ( e.g., ghcr.io/falcosecurity/plugins/plugin/container:0.4.1). Now all artifacts are verified regardless of how they are referenced.\nSignature verification fix for authenticated registries Signature verification now works correctly on private/authenticated registries. Previously, verification would fail with authentication errors even though the artifact pull succeeded, and credentials were not being passed to the signature verification component.\nSupported authentication methods:\nBasic auth (Docker credentials) OAuth2 client credentials GCP Workload Identity (for GKE deployments) For more details see fix(signature): pass registry credentials to cosign for signature verification\nBreaking changes and deprecations This version includes breaking changes you should be aware of before upgrading.\nBump drivers minimum required kernel version to 3.10 Falco 0.43.0 introduces a breaking change regarding the Falco drivers. Starting with drivers version 9.1.0+driver, the minimum required Linux kernel version has been bumped to 3.10. In practice, this only affects the kmod driver and means that the kernel module will explicitly fail to compile on kernels older than 3.10. This choice is motivated by the fact that even Linux 3.10 is a 12-year-old kernel, and its support ended in 2017: maintaining support for older kernels is a maintenance burden and limits progress. This change enables the team to focus on modernizing the codebase and improving stability for current environments.\nDeprecation warnings Falco 0.43.0 introduces several deprecation warnings to help users migrate to newer components:\nLegacy eBPF probe deprecation: using the legacy eBPF probe (engine.kind=ebpf) will now generate warnings gVisor engine deprecation: using the gVisor engine (engine.kind=gvisor) will now generate warnings gRPC deprecation: using the gRPC output or the gRPC server (grpc_output.enabled=true or grpc.enabled=true), will now generate warnings Try it out Interested in trying out the new features? Use the resources below to get started.\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Stay connected Join us on social media and in our community calls, held every other Wednesday! It's always great to have new members in the community, and we're looking forward to hearing your feedback and ideas.\nYou can find all the most up-to-date information at https://falco.org/community/.\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.43.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-43-0/"},{"category":"blog","content":"The GPG key used to sign official Falco packages (RPM and DEB) is set to expire on January 17, 2026. To ensure the security and continuity of our software distribution, the Falco maintainers will be rotating to a new 4096-bit RSA key.\nWe have designed a two-phase \u0026quot;Soft Launch\u0026quot; strategy to make this transition as smooth as possible, providing a one-month transition window before the old key is retired.\nThe Rotation Plan To avoid immediate disruption, we are rolling out the new key in two distinct phases. You can follow the detailed progress in our tracking issue #3750.\nPhase 1: Soft Launch (Dec 12, 2025) What happens: The new GPG key has been published and added to our repository configuration. Dev Builds: Will begin using the New Key immediately. Stable Builds: No stable releases are planned for this phase. If any hotfixes are released, they will be signed with New Key as well. Key Bundle: The official key URL has been updated to serve a bundle containing both the Old (valid) and New (valid) keys. Phase 2: Hard Cut-Over (Jan 12–17, 2026) What happens: This is the maintenance window where we fully switch to the new key. Mass Resign: All existing stable packages on download.falco.org will be resigned with the New Key. Revocation: The Old Key will be officially revoked and removed from the active bundle. Impact: If you have not updated your keyring by this date, your package manager (apt or yum) will reject updates with a signature verification error. Action Items for Users We strongly recommend all users update their GPG keyring before January 12, 2026 to avoid interruption.\nNew Users If you are installing Falco for the first time following our Install on a host (DEB,RPM) instructions, no action is required. The installation process will guide you to fetch the new key bundle, ensuring you are ready for both phases.\nExisting Users If you have an existing Falco installation, you must manually import the new key. We have updated the key file at our standard URL to include both the old and new keys, allowing you to transition safely.\nFor apt users, to update your keyring, run the following command:\n# Download the updated key bundle (Old + New) and import it curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \\ sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg For yum users, to update your keyring, run the following command:\n# Download the updated key bundle (Old + New) and import it rpm --import https://falco.org/repo/falcosecurity-packages.asc Note: These commands overwrite the existing keyring file with the new bundle. Since the bundle contains both keys, your current installation will continue to work immediately, and will remain working after the January cut-over.\nFor more details on apt and yum specific instructions, please refer to the Install on a host (DEB,RPM) page of our documentation.\nSummary Deadline: Update your keys before Jan 12, 2026. Old Key (Expiring Jan 17, 2026): falcosecurity-14CB7A8D.asc (Fingerprint 2005399002D5E8FF59F28CE64021833E14CB7A8D) New Key: falcosecurity-B35B1B1F.asc (Fingerprint 478B2FBBC75F4237B731DA4365106822B35B1B1F) Tracking Issue: falcosecurity/falco#3750 If you encounter any issues during this transition, please reach out to us on the #falco channel on Kubernetes Slack or open an issue on GitHub.\nThank you for your attention and cooperation in keeping Falco secure!\n","summary":"","tags":["Falco","Announcements"],"title":"GPG Key Rotation for Falco Packages (2026)","url":"https://v0-43--falcosecurity.netlify.app/blog/gpg-key-rotation-2026/"},{"category":"blog","content":"Dear Falco Community, today we are happy to announce the release of Falco 0.42.0!\nThis release brings exciting new capabilities, including the capture feature, significant performance improvements, and important bug fixes that enhance Falco's capabilities. During this release cycle, we merged:\n52 PRs on Falco, including 23 release note-worthy changes 110 PRs on Falco libs, including 47 release note-worthy changes 102 PRs on Falco drivers, including 29 release note-worthy changes We upgraded libs to version 0.22.1 and drivers to v9.0.0+driver. Thank you to our maintainers and contributors. This would not have been possible without your support and dedication!\nTo learn everything about the changes, read on!\nWhat's new? TL;DR Key features:\nCapture recording feature; Drop enter initiative for performance; Plugin event schema validation; Thread table auto-purging configuration; Static fields; Key fixes:\nFix thread table memory leak when parsing vfork (or equivalent clone/clone3 with CLONE_VFORK) exit from the caller process; Enable handling of multiple actions configured with syscall_event_drops.actions; Disable dry-run restarts when Falco runs with config-watching disabled; Fix abseil-cpp for Alpine build; Fix detection sandbox containers for CRI and containerd runtimes (container plugin); Stability improvements for container plugin and static linking of libgcc/libstdc++ for legacy compatibility; This release also comes with breaking changes that you should be aware of before upgrading.\nMajor features and improvements The 0.42.0 release contains a new capture feature and significant performance improvements. Here is a list of the key new capabilities.\nCapture recording feature Falco 0.42.0 introduces the new capture recording feature, now available at sandbox maturity. This capability allows Falco to generate .scap files whenever a detection rule is triggered automatically.\nEach capture contains a detailed trace of system calls around the event, providing forensic-level visibility into what happened. The recordings can be opened directly in Stratoshark for Wireshark-style analysis of runtime behavior.\nThe capture system is fully configurable: you can enable global recording or tie captures to specific Falco rules for targeted runtime snapshots.\nWhen targeting specific Falco rules (by setting mode: rules, as shown in the configuration below), users can modify individual rules to enable capture by adding capture: true and optionally capture_duration to specific rules. For example:\n- rule: Suspicious File Access desc: Detect suspicious file access patterns condition: \u0026gt; open_read and fd.name startswith \u0026#34;/etc/\u0026#34; output: \u0026gt; Suspicious file access (user=%user.name command=%proc.cmdline file=%fd.name) priority: WARNING capture: true capture_duration: 10000 # Capture for 10 seconds when this rule triggers This configuration will capture events for 10 seconds whenever the \u0026quot;Suspicious File Access\u0026quot; rule is triggered, overriding the default duration.\nFind below the configuration snippet to enable the capture feature in falco.yaml:\ncapture: # -- Set to true to enable event capturing. enabled: false # -- Prefix for capture files. Falco appends a timestamp and event number to ensure unique filenames. path_prefix: /tmp/falco # -- Capture mode. Can be \u0026#34;rules\u0026#34; or \u0026#34;all_rules\u0026#34;. mode: rules # -- Default capture duration in milliseconds if not specified in the rule. default_duration: 5000 Learn more at KubeCon + CloudNativeCon North America 2025:\nProject Lightning Talk: When Falco Spots Trouble, The Shark Swims In - Gerald Combs, Falco Core Maintainer Beyond the Cloud(s): Falco's Ascent in Performance and Deep Visibility - Leonardo Grasso \u0026amp; Leonardo Di Giovanna, Sysdig Drop enter initiative We've just shipped a significant performance improvement: syscall enter events have been completely removed from our event pipeline.\nIn Falco, each system call traditionally used to generate two events: an enter event when syscall kernel processing starts (i.e., before its arguments are processed) and an exit event when the kernel processing completes. Now that we collect all relevant information on exit events, we can drop the generation and processing of enter events.\nNevertheless, for TOCTOU (Time-of-Check to Time-of-Use) mitigation, a few selected enter events are still monitored internally — their relevant data is captured and stored — but these events are no longer pushed downstream to the userspace processing pipeline.\nBy focusing solely on syscall exit events, we've nearly halved the number of events generated and processed by userspace, eliminating redundant data collection. This reduces the Falco instrumentation overhead, improving workloads' performance up to 20% (by reducing syscall execution latency). It also decreases Falco's CPU usage up to 30%, especially in high-syscall environments.\nFrom a developer's perspective, this also removes ambiguity about where syscall parameters should be defined, streamlines event processing logic, and makes event handling code cleaner and easier to maintain.\nOverall, you can expect better performance, leaner code, and a more predictable event model moving forward.\nFor more details, see:\nProposal [Tracking] Extend syscall exit events with syscall enter events parameters TOCTOU mitigation [Tracking] Drop syscall enter events Plugin event schema versioning Falco 0.42.0 introduces plugin event schema validation, enabling plugins to specify their compatible event schema version.\nIt provides an event schema validation system for syscall events consumed by plugins that offer parsing and/or field extraction capabilities, ensuring backward compatibility and clear error reporting for plugins that depend on specific Event Schema Versions.\nIf the plugin does not declare a required Schema Version, it is assumed to be compatible with 3.0.0, the initial major version when the plugin event schema validation was introduced.\nThe plugins should implement a new function of the Plugin API to declare the required schema version. Find below the signature of the new API function:\n// New plugin API functions for schema management typedef struct { ... // Event schema version check // // Return the minimum event schema version required by this plugin. // Required: no // Arguments: // - s: the plugin state, returned by init(). Can be NULL. // Return value: the event schema version string, in the following format: // \u0026#34;\u0026lt;major\u0026gt;.\u0026lt;minor\u0026gt;.\u0026lt;patch\u0026gt;\u0026#34;, e.g. \u0026#34;4.0.0\u0026#34;. // If the function is not implemented or NULL is returned, the plugin is assumed to be // compatible with schema version 3.0.0. // const char* (*get_required_event_schema_version)(ss_plugin_t* s); } plugin_api; For more details, see:\nPlugin system event schema versioning proposal Thread table auto-purging configuration We've added a few new falco_libs configurations for advanced users who want finer control over Falco's performance and resource usage. It introduces tunable parameters for Falco's internal thread table, which tracks active threads:\nthread_table_size defines the maximum number of entries. thread_table_auto_purging_interval_s controls how often stale threads are cleaned up. thread_table_auto_purging_thread_timeout_s sets how long inactive threads are kept before removal. These options let you balance memory efficiency, CPU usage, and state accuracy, with related metrics (n_drops_full_threadtable, n_store_evts_drops) available to guide tuning.\nStatic fields Falco 0.42.0 adds a new static_fields configuration object allowing users to add statically defined fields to the Falco engine. The following example illustrates how to specify new static fields:\nstatic_fields: foo: bar foo2: ${bar2} Notice that foo2: ${bar2} leverages the Falco's behavior of expanding env variables in config YAML.\nAfter specifying them, these fields can be used in normal rule conditions, by prepending the static. prefix (e.g.: evt.type=open and static.foo=bar). Moreover, if append_output.suggested_output is true, they'll be automatically appended to each rule output, in the form static_foo=bar.\nFor more details, see:\nFeature request PR adding the feature Breaking changes and deprecations ⚠️ This version comes with breaking changes that you should be aware of before upgrading.\nEvent direction and evt.dir deprecation Following the enter events initiative, the evt.dir field, as well as the concept of \u0026quot;direction\u0026quot;, have been deprecated in Falco 0.42.0 and will be removed in a future release. Until field removal and since Falco 0.42.0, specifying evt.dir='\u0026gt;' will match nothing, while specifying evt.dir='\u0026lt;' will match everything, with a warning informing the user about the deprecation. Users are encouraged to get rid of any reference to evt.dir, as its presence will result in an error at rules loading time after its removal.\nPlugin API changes Old plugins consuming syscall events not declaring the required event schema version will be incompatible with Falco 0.42.0 and later. Deprecation warnings Falco 0.42.0 introduces several deprecation warnings to help users migrate to newer APIs:\nevt.dir field deprecation: Rules using the deprecated evt.dir field will now generate warnings; Enter events drop stats: Prometheus metrics for enter events drop statistics have been deprecated; Configuration warnings: Enhanced warning system for deprecated configuration options; Try it out Interested in trying out the new features? Use the resources below to get started.\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Stay connected Join us on social media and in our community calls, held every other Wednesday! It's always great to have new members in the community, and we're looking forward to hearing your feedback and ideas.\nYou can find all the most up-to-date information at https://falco.org/community/.\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.42.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-42-0/"},{"category":"blog","content":"Dear Falco Community, today we are happy to announce the release of Falco 0.41.0!\nThis version brings several new features, performance enhancements, and bug fixes that streamline Falco’s detection capabilities. During this release cycle, we merged more than 50 PRs on Falco and around 130 PRs for libs and drivers, version 0.21.0 and version 8.1.0, respectively. Thank you to our maintainers and contributors. This would not have been possible without your support and dedication!\nTo learn everything about the changes, read on!\nWhat’s new? TL;DR Key features:\nReimplemented container engines support from scratch; A Kubernetes operator is taking shape; Falco's config_files configuration gained support to specify the merge strategy; Modern eBPF driver is now capable of trying to load multiple programs for each event; consequently, sendmmsg and recvmmsg will now make use of bpf_loop eBPF helper where available, boosting their performances; New proc.aargs field available, ie: a lookup for an ancestor args field; proc.args gained support for indexed access, to only check a certain argument; json_include_output_fields configuration key for Falco to control whether output fields are included in the JSON message; Ongoing work to improve libs code modularity; Key fixes:\nAvoid kmod crashing when a CPU gets enabled at runtime; Fixed Falco Prometheus metrics with multiple event sources enabled; Fixed RPM packages evaluation of RPM scripts; -o options do now correctly override included config_files; This release also comes with breaking changes that you should be aware of before upgrading.\nMajor features and improvements The 0.41.0 release contains a number of features and UX improvements. Here is a list of some of the key new capabilities.\nReimplemented container engines support In the Falco 0.41.0 release, the Falco team has completely revised its support for container engines. Key improvements include:\nContainer support is now a plugin; The plugin will attach a listener to the engine's SDKs onCreate signal; since onCreate comes way before onStart, we have plenty of time to deliver the container's metadata before the first process in the container is even started; For now, it is bundled within Falco to avoid breaking changes, but in the future, it will need to be downloaded through falcoctl; These changes should address all issues related to missing container metadata.\nKubernetes operator In Falco 0.41.0, we worked hard to create a Falco k8s operator: https://github.com/falcosecurity/falco-operator/. For now, this is considered a technical preview, but we will deliver a fully functional operator very soon. Expect more news in a new blog post!\nSecurity best practices improvements We are grateful for the suggestions we received from security experts and adopters in our community, and so we implemented the following enhancements:\nThe modern eBPF probe will no longer store security sensitive settings in the .bss mmapable segment but will use dedicated maps instead. This is a security best practice because it prevents other processes running with elevated privileges from tampering with the map file descriptor, which would be harder to detect. We would like to thank Mouad Kondah for suggesting this change!\nFalco will no longer consider rule files or contents of rule directories that do not have a .yml/.yaml extension. This prevents accidental processing of files that are not related to rules. We would like to thank our user Travis Smith for suggesting this change!\nBreaking changes and deprecations ⚠️ This version comes with breaking changes, mostly in the configuration interface.\nRemoved command line options and equivalent configuration options We removed the already deprecated options -S/--snaplen, -A, and -b, and it is now possible to achieve the same result through the Falco configuration:\nfor -S/--snaplen: falco_libs.snaplen config key; for -A: base_syscalls.all config key; for -b: buffer_format_base64 config key; The configuration options for the container engines, added in 0.40.0, have been completely dropped in favor of the new plugin init configuration which can be found at https://github.com/falcosecurity/plugins/tree/main/plugins/container#configuration.\nYou can find more information on breaking changes in the tracking issue.\nBehavior changes Falco will now only consider and consequently load rules whose name ends in .yml or .yaml.\nDropped features syslog related fields were dropped by libs, since they were unused.\nAlso, as a consequence of the new container plugin, some breaking changes had to take place:\nthe musl build is inherently not able to load plugins; that means that it loses container metadata support; falcosecurity_scap_n_containers and falcosecurity_scap_n_missing_container_images metrics are now moved to the plugin, and their name now have the falcosecurity_plugins_ prefix; -pc and -pk command line options are now ineffective; it is up to the container and k8smeta plugins to declare suggested fields to be used as output fields; consequently, container_image=%container.image.repository and k8s_ns=%k8s.ns.name changed their name to container_image_repository= and k8s_ns_name=; Deprecations In Falco 0.41.0, we have deprecated the following options:\n-p cli flag; the only remaining user for it is gVisor, which will be ported to a plugin sooner or later and will then make use of the suggested output fields plugin API; Try it out Interested in trying out the new features? Use the resources below to get started.\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package What’s next? Falco is more mature with each release. Following its graduation, we have published the roadmap for version 1.0.0, which is guiding us in the next steps. For the next release, you can expect more stability, a refined k8s operator, improved performance, and, as always, new detections and fixes.\nStay connected Join us on social media and in our weekly community calls! It’s always great to have new members in the community, and we’re looking forward to hearing your feedback and ideas.\nYou can find all the most up-to-date information at https://falco.org/community/.\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.41.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-41-0/"},{"category":"blog","content":"The recently discovered CVE for the GitHub action tj-actions/changed-files brought to light a topic that is really critical for companies: supply chain attacks. With that, we want to discuss and show a bit about how Falco can help your organization detect this kind of attack and other suspect behaviors inside your CI/CD pipeline.\nWhat is Falco? Falco is a cloud native security tool that provides runtime security across hosts, containers, Kubernetes, and cloud environments. It leverages custom rules on Linux kernel events and other data sources through plugins, enriching event data with contextual metadata to deliver real-time alerts. Falco enables the detection of abnormal behavior, potential security threats, and compliance violations.\nWhat is Falco Actions? Falco Actions enable you to run Falco in GitHub Actions to detect suspicious behavior in your CI/CD workflows. If you run it in a pull request, the action will create a comment with the findings.\nThanks to ad-hoc Falco rules specific to this use case, these GitHub actions can monitor your GitHub runner and detect software supply chain attacks.\nUsing Falco Actions To have Falco inside your pipeline, you need to add these two actions:\nfalcosecurity/falco-actions/start falcosecurity/falco-actions/stop Below you can see an example:\nname: CI on: push: pull_request: jobs: build: runs-on: ubuntu-latest permissions: contents: read actions: read steps: - uses: actions/checkout@v4 - name: Start Falco uses: falcosecurity/falco-actions/start@main with: mode: live falco-version: \u0026#39;0.40.0\u0026#39; verbose: true - name: My Custom Step run: | echo \u0026#34;This is my custom step\u0026#34; - name: Stop Falco uses: falcosecurity/falco-actions/start@main with: mode: live verbose: true OBS: main is being used here only to simplify how it works, you should always pin your dependencies to a specific commit SHA.\nAfter the execution, you will be able to see the results at the github action summary.\nIf you want a more detailed report, you can use the action falcosecurity/falco-actions/analyze; it will allow you to have a better report with information like:\nFalco rules triggered during steps' execution. Contacted IPs Contacted DNS domains SHA256 hash of spawned executables Spawned container images Written files A summary of the report generated with OpenAI Reputation of Contacted IPs Reputation of SHA256 hashes For more informations about the usage, you can check the github repository for the actions.\nDefault rules file By default, Falco action will detect a variety of events, following the default CICD rules, that can be overridden if you want.\nIn the example from the tj-actions/changed-files exploit, one rule that would be triggered is the Process Dumping Memory of Others, which was used during the exploit to dump environment variables from the main process and print them as part of the Github runner execution.\nThe Falco team is always adding new rules to ensure our users get value out of the box, but you can also write your own rules according to your company policy.\nConclusions These actions are just the beginning of having the Falco capabilities inside the CI/CD pipelines. You can customize and have your own set of rules, keeping all environments and scenarios covered and protected from supply chain attacks.\nLet's meet! As always, we meet every 2 weeks on Wednesday at 4pm UTC in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Enjoy 😎,\nIgor and Edson\n","summary":"","tags":["Falco","Kubernetes","cicd","Github Action","SupplyChain"],"title":"Detecting Supply Chain Attacks with Falco Actions","url":"https://v0-43--falcosecurity.netlify.app/blog/detecting-supplychain-attacks-with-falco-action/"},{"category":"blog","content":"Detecting threats in a Kubernetes cluster can be challenging, we generally don't know where and how to start. The good news is that we have an amount of valuable logs that can help us to know what is happened in the cluster. Indeed, each action requested or done by a user or an app, in a cluster, is recorded in Audit Logs. Kubernetes events are key to understanding the behavior of a cluster.\nWe already provide plugins that let you parse Audit Logs and use Falco to detect threats from GKE, EKS and AKS clusters. With our latest plugin, you'll now have the same powerful threat detection capabilities for your OVHcloud MKS clusters 🎉.\nWhat is Falco? Falco is an Open Source cloud-native runtime security tool. It provides near real-time threat detection for cloud, container, and Kubernetes workloads by leveraging runtime insights. Falco can monitor events from various sources, including the Linux kernel, and enrich them with metadata from the Kubernetes API server, container runtime, and more.\nFalco can receive Events, compare them to a set of Rules to determine the actions to perform and generate Alerts to different endpoints.\nWhat is the OVH MKS Audit Logs plugin? The OVH audit logs plugin (k8saudit-ovh) extends Falco's capabilities to OVHcloud Managed Kubernetes Service (MKS) clusters, providing you with the same security insights and threat detection Falco already offers for GKE, EKS and AKS environments.\nWith this plugin, you can seamlessly integrate MKS Audit Logs into Falco's event processing pipeline, enabling it to identify anomalies, suspicious activities, and policy violations within your MKS-based workloads.\nConcretely, when a user executes some kubectl commands in an OVHcloud MKS cluster, Audit Logs will be generated. Falco is listening to them, and depending on the configured rules to follow, it will generate some alerts.\nUsing OVH MKS Audit Logs plugin In order to use the OVH MKS Audit Logs plugin, you must follow several steps:\ndeploy an OVHcloud LDP (Logs Data Platform) create a data stream into this LDP connect an OVHcloud MKS cluster to the data stream (to send Audit Logs into it) To be able to access our Kubernetes clusters' Audit Logs, you need to deploy an LDP. LDP is the managed platform for collecting, processing, analyzing, and storing your logs of the OVHcloud products. Deploy an LDP (Bare Metal Cloud universe) with whatever plan you want.\nOVHcloud Kubernetes Audit Logs will be stored in a data stream. The OVHcloud Audit Logs Falco plugin receive the audit logs through Websocket so you need to enable Websocket broadcasting when you create the data stream on LDP.\nRetrieve the Websocket URL, follow the guide to do so. The Websocket address have this kind of format: wss://gra.logs.ovh.com/tail/?tk=\nFinally, you have to connect a MKS cluster to the LDP data stream.\nConfiguring Falco to use OVH Audit Logs plugin Running locally If you have a Falco running locally, using falcoctl, add the falcosecurity index (if it's not already the case) and install the k8saudit-ovh Falco plugin:\n# Add falcosecurity index sudo falcoctl index add falcosecurity https://falcosecurity.github.io/falcoctl/index.yaml # Install k8saudit-ovh Falco plugin sudo falcoctl artifact install k8saudit-ovh Fill your falco.yaml file in order to add the plugin configuration:\nplugins: - name: k8saudit-ovh library_path: /usr/share/falco/plugins/libk8saudit-ovh.so open_params: \u0026#34;\u0026lt;OVH LDP WEBSOCKET URL\u0026gt;\u0026#34; # gra\u0026lt;x\u0026gt;.logs.ovh.com/tail/?tk=\u0026lt;ID\u0026gt; - name: json library_path: libjson.so init_config: \u0026#34;\u0026#34; load_plugins: [k8saudit-ovh, json] stdout_output: enabled: true Running in a Kubernetes cluster If you have a Falco running in a Kubernetes cluster (on OVHcloud MKS or on another cluster), deployed with Helm, create a values.yaml file with the following content:\ntty: true kubernetes: false # Just a Deployment with 1 replica (instead of a Daemonset) to have only one Pod that pulls the MKS Audit Logs from a OVHcloud LDP controller: kind: deployment deployment: replicas: 1 falco: rule_matching: all rules_files: - /etc/falco/k8s_audit_rules.yaml - /etc/falco/rules.d plugins: - name: k8saudit-ovh library_path: libk8saudit-ovh.so open_params: \u0026#34;gra\u0026lt;x\u0026gt;.logs.ovh.com/tail/?tk=\u0026lt;ID\u0026gt;\u0026#34; # Replace with your LDP Websocket URL - name: json library_path: libjson.so init_config: \u0026#34;\u0026#34; # Plugins that Falco will load. Note: the same plugins are installed by the falcoctl-artifact-install init container. load_plugins: [k8saudit-ovh, json] driver: enabled: false collectors: enabled: false # use falcoctl to install automatically the plugin and the rules falcoctl: artifact: install: enabled: true follow: enabled: true config: indexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml artifact: allowedTypes: - plugin - rulesfile install: resolveDeps: false refs: [k8saudit-rules:0, k8saudit-ovh:0.1, json:0] follow: refs: [k8saudit-rules:0] This values.yaml file will install Falco with the k8saudit-ovh and the json plugins.\nInstall the latest version of Falco with helm install command:\n$ helm install falco --create-namespace --namespace falco --values=values.yaml falcosecurity/falco This command will install the latest version of Falco, with the k8saudit-ovh and json plugins, and create a new falco namespace.\nOr if you already have Falco deployed in a Kubernetes cluster, you can use the helm update command instead:\n$ helm update falco --create-namespace --namespace falco --values=values.yaml falcosecurity/falco Once the Falco pod is ready, run the following command to see the logs:\nkubectl logs -l app.kubernetes.io/name=falco -n falco -c falco You should see logs like that:\n$ kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco Mon Feb 10 09:15:35 2025: /etc/falco/k8s_audit_rules.yaml | schema validation: ok Mon Feb 10 09:15:35 2025: Hostname value has been overridden via environment variable to: my-pool-1-node-921b61 Mon Feb 10 09:15:35 2025: The chosen syscall buffer dimension is: 8388608 bytes (8 MBs) Mon Feb 10 09:15:35 2025: Starting health webserver with threadiness 2, listening on 0.0.0.0:8765 Mon Feb 10 09:15:35 2025: Loaded event sources: syscall, k8s_audit Mon Feb 10 09:15:35 2025: Enabled event sources: k8s_audit Mon Feb 10 09:15:35 2025: Opening \u0026#39;k8s_audit\u0026#39; source with plugin \u0026#39;k8saudit-ovh\u0026#39; {\u0026#34;hostname\u0026#34;:\u0026#34;my-pool-1-node-921b61\u0026#34;,\u0026#34;output\u0026#34;:\u0026#34;09:15:40.698757000: Warning K8s Operation performed by user not in allowed list of users (user=csi-cinder-controller target=csi-6afb06dce281b86b7bab718b5d966dc261b2b1554941ae449519a128cb2e3fb3/volumeattachments verb=patch uri=/apis/storage.k8s.io/v1/volumeattachments/csi-6afb06dce281b86b7bab718b5d966dc261b2b1554941ae449519a128cb2e3fb3/status resp=200)\u0026#34;,\u0026#34;output_fields\u0026#34;:{\u0026#34;evt.time\u0026#34;:1739178940698757000,\u0026#34;ka.response.code\u0026#34;:\u0026#34;200\u0026#34;,\u0026#34;ka.target.name\u0026#34;:\u0026#34;csi-6afb06dce281b86b7bab718b5d966dc261b2b1554941ae449519a128cb2e3fb3\u0026#34;,\u0026#34;ka.target.resource\u0026#34;:\u0026#34;volumeattachments\u0026#34;,\u0026#34;ka.uri\u0026#34;:\u0026#34;/apis/storage.k8s.io/v1/volumeattachments/csi-6afb06dce281b86b7bab718b5d966dc261b2b1554941ae449519a128cb2e3fb3/status\u0026#34;,\u0026#34;ka.user.name\u0026#34;:\u0026#34;csi-cinder-controller\u0026#34;,\u0026#34;ka.verb\u0026#34;:\u0026#34;patch\u0026#34;},\u0026#34;priority\u0026#34;:\u0026#34;Warning\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Disallowed K8s User\u0026#34;,\u0026#34;source\u0026#34;:\u0026#34;k8s_audit\u0026#34;,\u0026#34;tags\u0026#34;:[\u0026#34;k8s\u0026#34;],\u0026#34;time\u0026#34;:\u0026#34;2025-02-10T09:15:40.698757000Z\u0026#34;} {\u0026#34;hostname\u0026#34;:\u0026#34;my-pool-1-node-921b61\u0026#34;,\u0026#34;output\u0026#34;:\u0026#34;09:15:57.508657000: Warning K8s Operation performed by user not in allowed list of users (user=yacht target=my-pool-1.18051c0a88716868/events verb=patch uri=/api/v1/namespaces/default/events/my-pool-1.18051c0a88716868 resp=403)\u0026#34;,\u0026#34;output_fields\u0026#34;:{\u0026#34;evt.time\u0026#34;:1739178957508657000,\u0026#34;ka.response.code\u0026#34;:\u0026#34;403\u0026#34;,\u0026#34;ka.target.name\u0026#34;:\u0026#34;my-pool-1.18051c0a88716868\u0026#34;,\u0026#34;ka.target.resource\u0026#34;:\u0026#34;events\u0026#34;,\u0026#34;ka.uri\u0026#34;:\u0026#34;/api/v1/namespaces/default/events/my-pool-1.18051c0a88716868\u0026#34;,\u0026#34;ka.user.name\u0026#34;:\u0026#34;yacht\u0026#34;,\u0026#34;ka.verb\u0026#34;:\u0026#34;patch\u0026#34;},\u0026#34;priority\u0026#34;:\u0026#34;Warning\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Disallowed K8s User\u0026#34;,\u0026#34;source\u0026#34;:\u0026#34;k8s_audit\u0026#34;,\u0026#34;tags\u0026#34;:[\u0026#34;k8s\u0026#34;],\u0026#34;time\u0026#34;:\u0026#34;2025-02-10T09:15:57.508657000Z\u0026#34;} {\u0026#34;hostname\u0026#34;:\u0026#34;my-pool-1-node-921b61\u0026#34;,\u0026#34;output\u0026#34;:\u0026#34;09:15:57.807013000: Warning K8s Operation performed by user not in allowed list of users (user=yacht target=my-pool-1/nodepools verb=update uri=/apis/kube.cloud.ovh.com/v1alpha1/nodepools/my-pool-1/status resp=200)\u0026#34;,\u0026#34;output_fields\u0026#34;:{\u0026#34;evt.time\u0026#34;:1739178957807013000,\u0026#34;ka.response.code\u0026#34;:\u0026#34;200\u0026#34;,\u0026#34;ka.target.name\u0026#34;:\u0026#34;my-pool-1\u0026#34;,\u0026#34;ka.target.resource\u0026#34;:\u0026#34;nodepools\u0026#34;,\u0026#34;ka.uri\u0026#34;:\u0026#34;/apis/kube.cloud.ovh.com/v1alpha1/nodepools/my-pool-1/status\u0026#34;,\u0026#34;ka.user.name\u0026#34;:\u0026#34;yacht\u0026#34;,\u0026#34;ka.verb\u0026#34;:\u0026#34;update\u0026#34;},\u0026#34;priority\u0026#34;:\u0026#34;Warning\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Disallowed K8s User\u0026#34;,\u0026#34;source\u0026#34;:\u0026#34;k8s_audit\u0026#34;,\u0026#34;tags\u0026#34;:[\u0026#34;k8s\u0026#34;],\u0026#34;time\u0026#34;:\u0026#34;2025-02-10T09:15:57.807013000Z\u0026#34;} Let's test it! In order to test Falco we need to know which rules are installed by default. In our case, as we defined it in the values.yaml file, the k8saudit-ovh plugin follow the k8s_audit_rules.yaml file. You can take a look at them in order to know them.\nIn this blog post we will test one of the well-known default k8s audit rules:\n- rule: Attach/Exec Pod desc: \u0026gt; Detect any attempt to attach/exec to a pod condition: kevt_started and pod_subresource and (kcreate or kget) and ka.target.subresource in (exec,attach) and not user_known_exec_pod_activities output: Attach/Exec to pod (user=%ka.user.name pod=%ka.target.name resource=%ka.target.resource ns=%ka.target.namespace action=%ka.target.subresource command=%ka.uri.param[command]) priority: NOTICE source: k8s_audit tags: [k8s] This rule is interesting because an event will be generated if/when an user execute commands in a pod.\nLet’s test the rule!\nIn a tab of your terminal, watch the coming logs:\n$ kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco -f In an another tab of your terminal, create a Nginx pod and execute a command into it:\n$ kubectl run nginx --image=nginx $ kubectl exec -it nginx -n hello-app -- cat /etc/shadow Several seconds laters, in the logs you should see this you will see this Attach/Exec to pod logs:\n... {\u0026#34;hostname\u0026#34;:\u0026#34;my-pool-1-node-921b61\u0026#34;,\u0026#34;output\u0026#34;:\u0026#34;09:29:46.302906000: Notice Attach/Exec to pod (user=kubernetes-admin pod=nginx-676b6c5bbc-4xc6t resource=pods ns=hello-app action=exec command=cat)\u0026#34;,\u0026#34;output_fields\u0026#34;:{\u0026#34;evt.time\u0026#34;:1739179786302906000,\u0026#34;ka.target.name\u0026#34;:\u0026#34;nginx-676b6c5bbc-4xc6t\u0026#34;,\u0026#34;ka.target.namespace\u0026#34;:\u0026#34;hello-app\u0026#34;,\u0026#34;ka.target.resource\u0026#34;:\u0026#34;pods\u0026#34;,\u0026#34;ka.target.subresource\u0026#34;:\u0026#34;exec\u0026#34;,\u0026#34;ka.uri.param[command]\u0026#34;:\u0026#34;cat\u0026#34;,\u0026#34;ka.user.name\u0026#34;:\u0026#34;kubernetes-admin\u0026#34;},\u0026#34;priority\u0026#34;:\u0026#34;Notice\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Attach/Exec Pod\u0026#34;,\u0026#34;source\u0026#34;:\u0026#34;k8s_audit\u0026#34;,\u0026#34;tags\u0026#34;:[\u0026#34;k8s\u0026#34;],\u0026#34;time\u0026#34;:\u0026#34;2025-02-10T09:29:46.302906000Z\u0026#34;} ... 💪\nLet's meet! If you have planned to go to the KubeCon + CloudNative Con EU 2025 at London, don't hesitate to stop at the Falco booth in the Project Pavillon!\nAs always, we meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Enjoy 😎,\nAurélie\n","summary":"","tags":["Falco","Kubernetes","Plugin","OVHcloud","MKS","auditlogs"],"title":"Detecting Threats in OVHcloud MKS Audit Logs with Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/detect-threats-falco-ovh-mks-audit-logs-plugin/"},{"category":"blog","content":"Troubleshooting Kubernetes events is challenging due to the multitude of data sources involved: container logs, Kubernetes events, cloud logs, and more. Among these sources, Kubernetes audit logs are especially valuable for identifying threats, as every action passing through the Kubernetes API server is recorded there.\nWe already provide plugins that let you parse and use Falco to detect threats in audit logs from GKE and EKS clusters. With our latest plugin, you'll now have the same powerful threat detection capabilities for your Azure AKS clusters.\nWhat is Falco? Falco is a Cloud Native Computing Foundation project that provides runtime threat detection. Out of the box, Falco examines syscalls to alert you to any suspicious activity. And, since containers share the same kernel as their host, Falco can monitor not only activity on the host but also activity on all of the containers running on that host. Moreover, Falco pulls data from both Kubernetes and the container runtime to add additional context to its alerts.\nWith Falco running on your GKE clusters you can be notified of a wide variety of events, such as:\nDid someone start a container with high privileges? Has someone shelled into a running container? Has an executable been added to the container after it was deployed? These are just a few examples. Falco has over 80 rules that can be used to make you aware of not only external threats but also when clusters aren't being operated in accordance with industry best practices.\nWhat is the AKS audit logs plugin? The AKS audit logs plugin extends Falco's capabilities to Microsoft Azure Kubernetes Service (AKS) clusters, providing you with the same security insights and threat detection Falco already offers for GKE and EKS environments. With this plugin, you can seamlessly integrate AKS audit logs into Falco's event processing pipeline, enabling it to identify anomalies, suspicious activities, and policy violations within your AKS-based workloads.\nUsing AKS audit logs plugin In order to use the AKS audit log plugin, you must first configure your AKS cluster to ship the logs where we can fetch them.\nThe current supported output source is Event hub, so when following the guide to configure your AKS audit logs, you must have Eventhub enabled. You can also optionally send it to other sources: Once you have the stream enabled, you must create or reuse a storage account blob container so that the plugin can track the last event that was consumed, which is done trough checkpoints.\nConfiguring Falco to use AKS audit logs plugin First, using falcoctl, download the plugin:\nsudo falcoctl artifact install k8saudit-aks In your falco.yaml file, you must add the plugin configuration and later enable the plugin\nconfig_files: - /etc/falco/config.d watch_config_files: true plugins: # - name: k8saudit # library_path: libk8saudit.so # init_config: \u0026#34;\u0026#34; # open_params: \u0026#34;http://:9765/k8s-audit\u0026#34; # - name: json # library_path: libjson.so - name: k8saudit-aks library_path: libk8saudit-aks.so init_config: event_hub_name: ${EVENTHUB_NAME} blob_storage_container_name: ${BLOB_STORAGE_CONTAINER_NAME} event_hub_namespace_connection_string: ${EVENTHUB_NAMESPACE_CONNECTION_STRING} blob_storage_connection_string: ${BLOB_STORAGE_CONNECTION_STRING} load_plugins: [k8saudit-aks] stdout_output: enabled: true Once they are exported, run Falco and after some seconds you'll logs informing the k8saudit-aks plugin was loaded:\nfalco -c /etc/falco/falco.yaml -r /etc/falco/falco_rules.yaml Tue Dec 17 18:02:07 2024: Opening \u0026#39;k8s_audit\u0026#39; source with plugin \u0026#39;k8saudit-aks\u0026#39; 2024/12/17 21:02:07 [k8saudit-aks] opened connection to blob storage 2024/12/17 21:02:07 [k8saudit-aks] opened blob checkpoint connection 2024/12/17 21:02:07 [k8saudit-aks] opened consumer client 2024/12/17 21:02:07 [k8saudit-aks] created eventhub processor Testing out! Append rule to falco_rules.yaml file:\n- rule: K8s Audit Event Detected desc: A test rule that detects any Kubernetes audit event condition: ka.req exists output: \u0026#34;K8s Audit Event Detected: %ka.req\u0026#34; priority: DEBUG source: k8s_audit tags: [testing, k8s_audit] $ falco -c /etc/falco/falco.yaml -r /etc/falco/falco_rules.yaml Then, you should see initialization message, followed by some events from your AKS cluster. Since we have debug enabled, you should see some events from the aksService:\nThu Dec 19 11:44:55 2024: Falco version: 0.39.2 (aarch64) Thu Dec 19 11:44:55 2024: Falco initialized with configuration files: Thu Dec 19 11:44:55 2024: /etc/falco/config.d/engine-kind-falcoctl.yaml | schema validation: ok Thu Dec 19 11:44:55 2024: /etc/falco/falco.yaml | schema validation: ok Thu Dec 19 11:44:55 2024: System info: Linux version 6.8.0-51-generic (buildd@bos03-arm64-031) (aarch64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec 5 13:32:09 UTC 2024 Thu Dec 19 11:44:55 2024: Loading plugin \u0026#39;k8saudit-aks\u0026#39; from file /usr/share/falco/plugins/libk8saudit-aks.so Thu Dec 19 11:44:55 2024: Loading plugin \u0026#39;json\u0026#39; from file /usr/share/falco/plugins/libjson.so Thu Dec 19 11:44:55 2024: Loading rules from: Thu Dec 19 11:44:55 2024: /etc/falco/falco_rules.yaml | schema validation: ok Thu Dec 19 11:44:55 2024: /etc/falco/falco_rules.local.yaml | schema validation: none Thu Dec 19 11:44:55 2024: /etc/falco/falco_aks_audit.yaml | schema validation: ok Thu Dec 19 11:44:55 2024: The chosen syscall buffer dimension is: 8388608 bytes (8 MBs) Thu Dec 19 11:44:55 2024: Starting health webserver with threadiness 4, listening on 0.0.0.0:8765 Thu Dec 19 11:44:55 2024: Loaded event sources: syscall, k8s_audit Thu Dec 19 11:44:55 2024: Enabled event sources: k8s_audit, syscall Thu Dec 19 11:44:55 2024: Opening \u0026#39;k8s_audit\u0026#39; source with plugin \u0026#39;k8saudit-aks\u0026#39; 2024/12/19 14:44:55 [k8saudit-aks] opened connection to blob storage 2024/12/19 14:44:55 [k8saudit-aks] opened blob checkpoint connection 2024/12/19 14:44:55 [k8saudit-aks] opened consumer client 2024/12/19 14:44:55 [k8saudit-aks] created eventhub processor Thu Dec 19 11:44:55 2024: Opening \u0026#39;syscall\u0026#39; source with modern BPF probe. Thu Dec 19 11:44:55 2024: One ring buffer every \u0026#39;2\u0026#39; CPUs. 10:52:03.348668000: Debug K8s Audit Event Detected: verb=create, user=aksService, groups=(system:masters,system:authenticated), target=\u0026lt;NA\u0026gt; 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!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Enjoy 😎,\nIgor\n","summary":"","tags":["Falco","Kubernetes","Plugin","Azure","AKS","auditlogs"],"title":"Falco plugin for collecting AKS audit logs","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-aks-audit-logs-plugin/"},{"category":"blog","content":"Today, we announce the release of Falco Talon 0.3.0 🦅!\nThree updates in a row, after Falco and Falcosidekick, it's time for Falco Talon to know a new version.\nWhat's new? The key feature this release brings is the new actionner kubernetes:sysdig. For those who are not familiar with sysdig, it's a CLI tool that allows to capture and record the syscalls, like tcpdump does for the network packets. Old brother of Falco, they share the same libs and filters.\nWith this new integration, when a suspicious event occurs in a pod, Talon triggers a capture and then exports the created artifact to AWS S3 or Minio. You can configure the duration and the amount of bytes captured for each syscall. Check out the docs to discover more settings.\nSee this example rule:\n- action: Capture the syscalls actionner: kubernetes:sysdig parameters: buffer_size: 2048 duration: 20 output: target: minio:s3 parameters: bucket: falco-talon prefix: /sysdig/ After the action has been completed, you'll find the capture in Minio:\nAnd you can run the CLI tool sysdig to explore it:\n❯ sysdig -r 2025-01-23T13-26-41Z_default_cncf-597d69dbd4-h9fcb_sysdig.scap.gz evt.type=execve and evt.dir=\u0026#34;\u0026gt;\u0026#34; 18563 14:26:38.376178286 0 bash (616444.616444) \u0026gt; execve filename=/usr/bin/apt 19163 14:26:38.394972623 0 apt (616445.616445) \u0026gt; execve filename=/usr/bin/dpkg 19599 14:26:38.399546432 0 apt (616446.616446) \u0026gt; execve filename=/usr/lib/apt/methods/http 20319 14:26:38.408846350 0 apt (616447.616447) \u0026gt; execve filename=/usr/lib/apt/methods/http 21775 14:26:38.453363037 0 apt (616448.616448) \u0026gt; execve filename=/usr/lib/apt/methods/gpgv 22335 14:26:38.461330752 0 apt (616449.616449) \u0026gt; execve filename=/usr/lib/apt/methods/gpgv 29434 14:26:38.481292691 0 gpgv (616451.616451) \u0026gt; execve filename=/usr/bin/apt-key 29604 14:26:38.486522901 0 apt-key (616453.616453) \u0026gt; execve filename=/usr/bin/apt-config 30183 14:26:38.494442117 0 apt-config (616454.616454) \u0026gt; execve filename=/usr/bin/dpkg 30422 14:26:38.497278722 0 apt-key (616455.616455) \u0026gt; execve filename=/usr/bin/apt-config 30996 14:26:38.504017535 0 apt-config (616456.616456) \u0026gt; execve filename=/usr/bin/dpkg You can also explore the captures with Stratoshark, a GUI based on Wireshark.\nTry it! 🏎️ In case you want to try out this Falco Talon 0.3.0, you can install the Helm chart following the instructions on the documentation\nLet's meet 🤝 We meet every two weeks on Wednesday in our community calls, if you want to know the latest and the greatest, you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nEnjoy 😎\n","summary":"","tags":["Talon","Release"],"title":"Falco Talon v0.3.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-talon-v0-3-0/"},{"category":"blog","content":"The year 2025 is well started now. We saw a few days ago the first release of Falco for the year. It's to let fly out a new version of Falcosidekick, the 2.31.0.\nNew output This release comes with a new output only, the last pillar of the observability with [OpenTelemetry].(https://opentelemetry.io/) that missing in Falcosidekick.\nOTLP Metrics You can now forward the Falco Events to the OpenTelemetery collector or any received understanding the protocol.\nNew features Here's a non exhaustive list of the great features and enhancements which come with this new release:\nBetter logger It was a ToDo for a while (even years), but it's now completed. The log system used by Falcosidekick has been replaced, without any breaking change for the users, but opening the door to more enhancements in the future.\nMore default labels for Loki The log lines forwarded to Loki contain now by default the source namespace and pod name, if present in the alert. It will allow to filter more easily the events you want to display in your dashboards. Thanks to @afreyermuth98.\nPayload format for Loki Some users asked for the possibility to forward the Falco alerts in their JSON format to Loki. You can now use the setting loki.format for.\nNATS/STAN subject The template for the subject where to push the messages for NATS/STAN was hardcoded, it can now be overridden with nats/stan.subjecttemplate. See the example config file.\nFixes Fix the missing templated fields as labels in Loki payload (PR#1091) Fix the creation error of a ClusterPolicyReport (PR#1100) Fix the missing custom headers for HTTP requests for Loki (PR#1107 thanks to @lsroe) Fix the wrong key format of custom fields for Prometheus (PR#1110 thanks to @rubensf) Conclusion You can find the full changelog here.\nThe respective Helm charts are already updated and allow you to test by yourself all these great new features. Just issue the helm repo update; helm upgrade --reuse-values -n falco command to do so.\nOnce again, thanks to all the adopters and contributors who helped and contributed to this project all these years. We would never have reached this success without you.\nGet started in Falco.org Check out the Falcosidekick project on GitHub. Check out the Falco Talon project docs. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Release"],"title":"Falcosidekick 2.31.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-2-31-0/"},{"category":"blog","content":"Dear Falco Community, today we are happy to announce the release of Falco 0.40.0!\nThis version brings several new features, performance improvements, and bug fixes that streamline Falco’s detection capabilities. During this release cycle, we merged more than 52 PRs on Falco and more than 150 PRs for libs and drivers, version 0.20.0 and version 8.0.0 respectively. Thank you to our maintainers and contributors, as this would not happen without your support and dedication!\nTo learn all about these changes, read on!\nWhat’s new? TL;DR Key features:\nStreamlined Falco docker images; Falco static build has been reintroduced for x86_64 binary using musl; New process filters allow to filter events based on process metadata; Added support for sendmmsg and recvmmsg syscalls parameters; Plugins suggested output fields are now available in the Falco engine; This release also comes with breaking changes that you should be aware of before upgrading.\nMajor features and improvements The 0.40.0 release contains a number of features and UX improvements. Here is a list of some of the key new capabilities.\nStreamlined Falco docker images In the Falco 0.40.0 release, the Falco team has streamlined the Docker images to improve usability and performance. The new images are designed to be more efficient and easier to use, providing a better experience for users deploying Falco in containerized environments.\nKey improvements include:\nReduced Image Size: The new images are smaller, which reduces the time required to pull and deploy them. Optimized Layers: The layers in the Docker images have been optimized to improve build times and caching efficiency. Enhanced Security: The images have been hardened to enhance security, reducing potential vulnerabilities. These changes make it easier to deploy and manage Falco in various environments.\nIntroducing new process filters A new set of process filters are made available in this release: proc.pgid, proc.pgid.name, proc.pgid.exe, proc.pgid.exepath, proc.is_pgid_leader. These filters enable users to filter events based on process metadata, such as the process name, executable path, and arguments. The new filters introduce the pgid field, which is directly obtained from the kernel. This ID corresponds to the host pid namespace, aiding in the creation of more reliable rules.\nPlugins suggested output fields The Falco engine now supports plugins that can suggest output fields. This feature allows plugins to provide additional context and information about an event, enhancing its visibility and understanding. The suggested output fields are displayed in the Falco output, giving users valuable insights into the event and its context. By leveraging this feature, Falco makes it easier for users to take advantage of the metadata provided by plugins and improve their security monitoring and incident response capabilities. New output fields are added only if the option is enabled and the plugin supports this new feature.\nKeep an eye on the existing plugins to be updated to support the new feature.\nBreaking changes and deprecations ⚠️ This version comes with breaking changes, mostly in the configuration interface.\nRemoved command line options and equivalent configuration options We removed the already deprecated options --cri, --disable-cri-async, and is now possible to achieve the same result through the Falco configuration. A new configuration options has been introduced to enable and configure the supported container engines in Falco:\ncontainer_engines: docker: enabled: true cri: enabled: true sockets: [\u0026#34;/run/containerd/containerd.sock\u0026#34;, \u0026#34;/run/crio/crio.sock\u0026#34;, \u0026#34;/run/k3s/containerd/containerd.sock\u0026#34;] disable_async: false podman: enabled: true lxc: enabled: true libvirt_lxc: enabled: true bpm: enabled: true Please keep in mind that the new configuration options are tagged as incubating and may change in the future.\nYou can also use the -o command line option:\n--cri \u0026lt;socket_path\u0026gt;: use -o container_engines.cri.enabled=true, -o container_engines.cri.sockets[]=\u0026lt;socket_path, -o container_engines.cri.disable_async=true instead to enable the CRI runtime and configure the socket path and disable the async mode. You can find more information on breaking changes in the tracking issue.\nNew docker images With the growing prominence of the modern eBPF probe, in Falco 0.38.0 we made the strategic decision to adopt it as the default driver for Falco. This shift brings key advantages to our distribution system by removing the need to bundle the full driver-building toolchain in the standard Falco distribution. As a result, we’re transitioning the default Falco image to a no-driver/distroless configuration, simplifying deployments and reducing system complexity. For users seeking alternative setups, a different container image will still be available.\nIn light of this change, we’ve re-evaluated all Docker images:\nImage Name Tag (aliases) Description falcosecurity/falco x.y.z (latest) Distroless image without driver building toolchain support, based on the latest released tar.gz of Falco. No tools or falcoctl included. falcosecurity/falco x.y.z-debian (latest-debian) Debian-based image without driver building toolchain support, based on the latest released Deb of Falco. May include some tools (e.g., jq, curl), but not falcoctl. falcosecurity/falco-driver-loader x.y.z (latest) Based on falcosecurity/falco:x.y.z-debian, plus driver building toolchain support and the latest version of falcoctl. Recommended only when modern eBPF is unsupported. falcosecurity/falco-driver-loader x.y.z-buster (latest) Similar to falcosecurity/falco-driver-loader, but based on a legacy Debian image (i.e., buster). Recommended only for old kernel versions. The following images have been deprecated and are not anymore available in the Falco 0.40.0 release:\nImage Name Reason falcosecurity/falco-distroless Deprecated in favor of falcosecurity/falco:x.y.z. falcosecurity/falco-no-driver Deprecated in favor of falcosecurity/falco:x.y.z-debian (essentially the same image with a new name). Deprecations In Falco 0.40.0, we have deprecated the following options:\n-S / --snaplen cli flag has been deprecated in favor of the falco_libs.snaplen configuration option; -A cli flag has been deprecated in favor of the base_syscalls.all configuration option; -b cli flag has been deprecated in favor of the buffer_format_base64 configuration option; Worthy of note Release artifacts are now built with zig, using very recent versions of clang. This change alone has resulted in up to 10% speedup in userspace benchmarks.\nThe first graph shows the events processed by userspace per second:\nThe following one shows the average of multiple runs of Google Benchmark framework embedded in libsinsp:\nAdditionally, artifacts now use jemalloc as the allocator library. This should help mitigate some memory fragmentation-related issues.\nFurthermore, Falco debug symbol files are now attached to GitHub releases. Falco is built in RelWithDebInfo mode, enabling users to download debug symbols and attach them to their debugging sessions.\nTry it out Interested in trying out the new features? Use the resources below to get started.\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package What’s next? Falco is more mature with each release. Following its graduation we have published the roadmap for version 1.0.0 which is guiding us in the next steps. For the next release, you can expect more stability, a new container plugin, refinements to our deployment methods with a k8s operator, and as always new detections and fixes.\nStay connected Join us on social media and in our weekly community calls! It’s always great to have new members in the community, and we’re looking forward to hearing your feedback and ideas.\nYou can find all the most up-to-date information at https://falco.org/community/.\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.40.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-40-0/"},{"category":"blog","content":"A few days after a new release of Falco Talon, our response engine, it's time for our favorite proxy forwarder to do the same.\nNew outputs A new release means new integrations. Thanks to our contributors for their helps.\nWebex Notify your team on Webex with the integration developed by @k0rventen.\nOTLP Metrics The adoption of Open Telemetry is bigger and bigger in the Cloud Native ecosystem, @ekoops introduced the OTLP Metrics in Falcosidekick.\nDatalog Logs The Falco alerts can be forwarded to Datadog as events for a while in Falcosidekick, you can now use their Logs service thanks to @yohboy.\nNew features Here's a non exhaustive list of the great features and enhancements which come with this new release:\nx3 throughput @alekmaus spotted a bottleneck with the http client used to forward the events to the outputs. His fix increases up to 300% the throughput!!!\nBetter integration with Elasticsearch @alekmaus worked hard to improve the integration with Elasticsearch. In addition improvments for the clients, new settings have been introduced, like the possibility to specify an ingest pipeline or an api key, to enable batching and compression. See the docs to know them all.\nBetter consistency for the Prometheus metrics Falco recently integrated a direct endpoint to expose metrics in the Prometheus format. After a lot of discussions between the maintainers and the community, a convention has been chosen for the names of the metrics. This release adapts the metrics exposed by Falcosidekick to follow this convention and have a consistency accross the different components of the ecosystem.\nBreaking changes: The renaming of the metrics might impact the queries for your alerts and dashboards.\nMulti hosts for AlertManager You can now specify a list of servers for the AlertManager output, which is a requirement when it's deployed in HA mode.\nFixes The contributors fixed several bugs, here's a non exhaustive list of the more important ones:\nFix PolicyReports created in the same namespace than the previous event (PR#978) Fix the missing customFields/extraFields in the Elasticsearch payload (PR#1033) Fix the incorrect key name for CloudEvent spec attribute (PR#1051) Conclusion You can find the full changelog here.\nThe respective Helm charts are already updated and allow you to test by yourself all these great new features. Just issue the helm repo update; helm upgrade --reuse-values -n falco command to do so.\nOnce again, thanks to all the adopters and contributors who helped and contributed to this project all these years. We would never have reached this success without you.\nGet started in Falco.org Check out the Falcosidekick project on GitHub. Check out the Falco Talon project docs. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Release"],"title":"Falcosidekick 2.30.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-2-30-0/"},{"category":"blog","content":"Today we announce the release of Falco Talon 0.2.0 🦅!\nFalco Talon 0.2.0 is a minor release that includes new actionners and outputs, add parameters to existing actionners, along one small fix on the check and print commands.\nFeatures Add gcp:function actionner: Now users can call GCP function to automate GCP tasks, with authentication and authorization out of the box. - action: Invoke GCP function actionner: gcp:function additional_contexts: - aws parameters: gcp_function_name: simple-http-function gcp_function_location: us-central1 Add gcp:gcs output Now users can send output directly to GCP Google Cloud Storage, same way as s3 and minio existing outputs. Add ignore_standalone_pods parameter for kubernetes:terminate actionner Allow to wait until the completion of kubernetes:drain by configuring max_wait_period and wait_period_excluded_namespaces Use smaller image for the kubernetes:tcpdump actionner Fixes An existing config.yaml file is not required anymore to check the syntax of your rules files. Try it! 🏎️ In case you just want to try out the Falco Talon 0.2.0, you can install the helm chart following the instructions on the documentation\nLet's meet 🤝 We meet every Wednesday in our community calls, if you want to know the latest and the greatest, you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nEnjoy 😎,\nIgor\n","summary":"","tags":["Talon","Release"],"title":"Falco Talon v0.2.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-talon-v0-2-0/"},{"category":"blog","content":"Today we announce the release of Falco 0.39.2 🦅!\nFixes Falco's 0.39.2 is a small patch release that includes some important bugfixes for modern eBPF driver:\ncheck cred field is not NULL before the access; this enables Falco back with modern eBPF driver to work on GKE address verifier issues on kernel versions \u0026gt;=6.11.4: there was a kernel-breaking change in the tail call ebpf API merged into the 6.11.4 to fix a CVE. Adapt our code to work again on these new versions. Thanks to everyone in the community for helping us spot these annoying bugs and improving Falco every day 🐛! You make Falco successful 🦅!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nTry it! 🏎️ As usual, in case you just want to try out the stable Falco 0.39.2, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Prefer to use a container image? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader Let's meet 🤝 We meet every Wednesday in our community calls, if you want to know the latest and the greatest, you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nEnjoy 😎,\nFederico\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.39.2","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-39-2/"},{"category":"blog","content":"In today's cloud-native world, securing Kubernetes environments has become increasingly critical as containerized workloads gain complexity. Falco is designed to monitor and detect anomalous activities in Kubernetes clusters and container environments. By continuously observing system calls and enriching event data with metadata, Falco ensures that any suspicious behavior is detected in real-time, protecting against threats like privilege escalations, file tampering, and network anomalies.\nIn this tutorial, we will guide you through deploying Falco with two powerful components: k8s-metacollector and the k8smeta plugin. These tools significantly enhance Falco’s security event detection by adding important Kubernetes context, such as pod names, namespaces, deployment details, to the alerts. Additionally, we will explore how to leverage the new append_output feature introduced in Falco version 0.39.0. This feature allows you to append extra metadata fields to Falco’s output, without the need to modify your rules.\nBy the end of this guide, you will have a Falco setup capable of detecting security issues in Kubernetes with enriched metadata output, ensuring you get a complete picture of your cluster’s security posture. Whether you're an experienced Kubernetes administrator or just starting to explore container security, this guide will help you make the most of Falco's capabilities in a Kubernetes environment.\nWhat You'll Learn: The purpose and benefits of using the k8s-metacollector and k8smeta plugin to enrich Falco alerts with Kubernetes-specific data. How to deploy Falco with the k8smeta plugin on a Kubernetes cluster. How to configure and use the append_output feature to enhance Falco alerts with additional metadata fields. Prerequisites: A working Kubernetes cluster and some familiarity with Kubernetes concepts. Basic knowledge of Falco and how it works. Helm installed on your system (for easy deployment of Falco). Let’s dive in and set up a Falco deployment that will give you deeper security insights for your Kubernetes workloads.\nStep 1: Understanding k8s-metacollector and k8smeta Plugin As Kubernetes has become the de facto platform for orchestrating containerized applications, it’s important to gain full visibility into what's happening within your cluster, especially when it comes to security monitoring. Falco can detect suspicious activities based on system calls, but to make these alerts more actionable, additional context about your Kubernetes resources (such as pod names, namespaces, and labels) is invaluable.\nThat’s where the k8s-metacollectorand k8smeta plugin come in.\nWhat is the k8s-metacollector? The k8s-metacollector is responsible for gathering Kubernetes metadata for security events and sending that information to Falco. It collects key information for different resources from your Kubernetes cluster, such as:\nPods; Namespaces; ReplicaSets; Services; Deployments; The collected metadata provides greater clarity about where and why certain events are happening, which is crucial for pinpointing and mitigating security incidents in large-scale Kubernetes environments. Without this context, security alerts may lack the detail needed for quick and effective response.\nWhat is the k8smeta Plugin? The k8smeta plugin is a source plugin for Falco that works in tandem with the k8s-metacollector. While Falco generates alerts based on detected anomalies, the k8smeta plugin enriches these alerts with Kubernetes-specific metadata, which allows you to understand exactly which Kubernetes entities (pods, deployments, namespaces) are involved in the detected event. This context is vital when you're trying to correlate security incidents with the resources they affect.\nKey benefits of the k8smeta plugin include:\nEnriched Alerts: Falco alerts become more informative with Kubernetes-specific data like pod names, namespaces, and deployment names. Improved Debugging: Knowing exactly which pod or namespace is involved in an alert can significantly reduce the time spent debugging and fixing security issues. Event Correlation: The plugin makes it easier to correlate low-level system events with higher-level Kubernetes concepts, providing a clearer view of what's happening in your cluster. By using the k8s-metacollector and k8smeta plugin together, you transform Falco’s raw system call data into rich, actionable insights that give you full visibility into your Kubernetes environment.\nStep 2: Installing Falco, k8s-metacollector, and k8smeta Plugin with Helm and Configuring append_output Deploying Falco along with the k8s-metacollector and the k8smeta plugin using Helm is a seamless process. This step will guide you through adding the Falco Security Helm chart repository, installing Falco, enabling the k8s-metacollector, and configuring the append_output feature to append Kubernetes metadata to Falco alerts.\nStep 2.1: Add the Falco Helm Chart Repository Before you install Falco, you need to add the official Falco Security Helm chart repository to your Helm setup. Run the following command:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts Update your local Helm repositories to ensure you’re using the latest chart version:\nhelm repo update Step 2.2: Install Falco with k8s-metacollector and append_output With the repository added, use the following command which includes the additional settings to enable the collection of Kubernetes metadata and to append this metadata to Falco alerts:\nhelm install falco falcosecurity/falco \\ --version 4.11.1 \\ --namespace falco \\ --create-namespace \\ --set collectors.kubernetes.enabled=true \\ --set tty=true \\ --set-json \u0026#39;falco.append_output=[{\u0026#34;match\u0026#34;: {\u0026#34;source\u0026#34;: \u0026#34;syscall\u0026#34;},\u0026#34;extra_output\u0026#34;: \u0026#34;pod_uid=%k8smeta.pod.uid, pod_name=%k8smeta.pod.name, namespace_name=%k8smeta.ns.name\u0026#34;}]\u0026#39; Breaking Down the Command:\nhelm install falco falcosercurity/falco: Installs Falco using the latest chart from the Falco Security repository. --version 4.11.1: Uses the 4.11.1 version of the chart. At the writing time it's the latest version. --namespace falco: Deploys Falco into the falco namespace. This helps keep Falco’s resources organized separately from other applications. --create-namespace: Automatically creates the falco namespace if it doesn’t already exist. --set collectors.kubernetes.enabled=true: Enables the k8s-metacollector and configures the k8smeta plugin. --set tty=true: Ensures that Falco logs are emitted as soon as possible. --set-json 'falco.append_output=...': Configures the append_output feature to append specific Kubernetes metadata fields to Falco’s alerts. Why Use the append_output Feature? The append_output feature allows you to enrich Falco alerts with additional metadata, providing a clearer view of which Kubernetes resources are involved in each security event. This context helps security teams quickly understand the severity and scope of an incident.\nFor example, an alert will now include:\npod_uid: To precisely identify the pod. pod_name: To know which pod triggered the alert. namespace_name: Namespace where the pod is running. Step 2.3: Verifying the Installation Once the installation is complete, you can verify that Falco and the k8s-metacollector are working as expected by checking the status of the Falco pod in the Falco namespace:\nkubectl get pods -n falco You should see the Falco pods running successfully.\nStep 3: Testing the Setup Now that everything is in place, it's time to test the setup by deploying a simple Nginx pod and triggering Falco to generate security alerts enriched with Kubernetes metadata.\nStep 3.1: Deploy an Nginx Pod To create some activity that Falco can monitor, start by deploying an Nginx pod in the falco namespace:\nkubectl run nginx --image=nginx --namespace falco This command will launch an Nginx container in the falco namespace.\nStep 3.2: Wait for the Nginx Pod to Run Confirm that the Nginx pod is up and running by checking its status:\nkubectl get pods -n falco Once the pod is in the Running state, you can proceed to the next step.\nStep 3.3: Exec Into the Nginx Pod to Trigger Alerts Exec into the running Nginx pod to simulate an interactive terminal session, which is something Falco is configured to detect:\nkubectl exec -it nginx -n falco -- /bin/bash This command opens a shell session inside the Nginx container. Inside the container, run some basic commands like ls or echo to generate system calls that Falco can monitor.\nStep 3.4: Check Falco Logs for Alerts After executing inside the Nginx pod, check the Falco logs to see if any alerts were triggered by the kubectl exec action:\nkubectl logs -n falco -l app.kubernetes.io/name=falco In the logs, you should see alerts related to the interactive terminal session such as:\n13:18:57.434030270: Notice A shell was spawned in a container with an attached terminal (evt_type=execve user=root user_uid=0 user_loginuid=-1 process=bash proc_exepath=/usr/bin/bash parent=containerd-shim command=bash terminal=34816 exe_flags=EXE_WRITABLE|EXE_LOWER_LAYER container_id=7cff9da475c6 container_image=docker.io/library/nginx container_image_tag=latest container_name=nginx k8s_ns=falco k8s_pod_name=nginx) pod_uid=2f20370c-6e0b-44b8-8ea1-2aa786d80f13, pod_name=nginx, namespace_name=falco This confirms that Falco is properly configured to detect activity inside the pod and append useful Kubernetes metadata to the alerts.\nKey Takeaways: In this tutorial, we explored how to deploy Falco with the k8s-metacollector and k8smeta plugin to enhance security monitoring in a Kubernetes environment. By enabling Falco’s append_output feature, we were able to enrich security alerts with vital Kubernetes metadata such as pod UID, pod name, and namespace, making the alerts more actionable and informative.\nEnhanced Alert Context: By appending Kubernetes metadata, you get more contextualized and meaningful alerts, enabling better incident investigation and faster resolution.\nSeamless Integration: Thanks to Helm, deploying Falco alongside the k8s-metacollector and k8smeta plugin is easy and efficient, requiring just a few simple commands.\nReal-Time Threat Detection: Falco continuously monitors system calls and Kubernetes events in real-time, ensuring that you’re always aware of potentially suspicious or malicious activities within your cluster.\n","summary":"","tags":["Falco","Kubernetes","Plugin","Enrichment","k8s-metacollector","k8smeta"],"title":"How to Deploy Falco with k8s-metacollector + k8smeta Plugin","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-k8smeta-plugin/"},{"category":"blog","content":"Today we announce the release of Falco 0.39.1 🦅!\nFixes Falco's 0.39.1 is a small patch release that includes some important bugfixes:\nFixed a crash when using plugin with event parsing capabilities (eg: k8smeta plugin) Fixed a bug while parsing -o key={object} command line arguments, when the object definition contains a comma Improved config json schema to allow null init_config for plugin info Thanks to everyone in the community for helping us with spotting these annoying bugs and improving Falco every day 🐛! You make Falco successful 🦅!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nTry it! 🏎️ As usual, in case you just want to try out the stable Falco 0.39.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Prefer to use a container image? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader Let's meet 🤝 We meet every Wednesday in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nEnjoy 😎,\nFederico\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.39.1","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-39-1/"},{"category":"blog","content":"Dear Falco Community, today we are happy to announce the release of Falco 0.39.0!\nThis version brings several new features, performance improvements, and bug fixes that streamline Falco’s detection capabilities. During this release cycle, we merged more than 50 PRs on Falco and more than 100 PRs for libs and drivers, version 0. 18.0 and version 7.3.0 respectively. Thank you to our maintainers and contributors, as this would not happen without your support and dedication!\nTo learn all about these changes, read on!\nWhat’s new? TL;DR Key features:\nBasename operator retrieves the basename of a given path; New fields added in proc and fd classes #1916 #1936; Regular expression operator can be used to match values in string fields; Append output allows to add output text or fields to a subset of loaded rules; Schema validation for config and rules files allows Falco to warn users when unknown keys are used; Improved engine selection in Kubernetes environments driver loader will automatically pick the most compatible driver for each node in the cluster. This release also comes with breaking changes that you should be aware of before upgrading.\nMajor features and improvements The 0.39.0 release contains a number of feature and UX improvements, here are list of some of the key new capabilities.\nNew Operators The basename() transformer operator extracts the base name, i.e. the filename without directory, of the input field. Note that the behavior ofbasename() in Falco is slightly different from the Unix basename program. For instance, basename (proc.exepath) will evaluate to \u0026quot;cat\u0026quot; for /usr/bin/cat but will evaluate to an empty string (\u0026quot;\u0026quot;) for /usr/bin/. This allows, for instance, to write expressions like basename(proc.exepath) = cat to match against the original executable name even if it has been symlinked without knowing the full path, or any other file name based detection.\nThe regex operator checks if a string field matches a regular expression. Please note that the regex operator is considerably slower (up to an order of magnitude) than the above operators that work with strings, which are highly recommended for simple comparisons. The supported regex flavor is from the Google RE2 library. Example: fd.name regex [a-z]*/proc/[0-9]+/cmdline.\nIntroducing the Append Output Feature In response to long-standing community requests, Falco has introduced a new feature in version 0.39.0 that allows users to add custom outputs and fields to events generated by Falco. This new functionality, called append_output, gives users greater control over the data produced by Falco rules.\nWith the append_output option, you can now easily add extra output to rules based on source, tag, or rule name—or even apply it to all rules without conditions. This option is configurable in the falco.yaml file and works by specifying a list of append entries, which are applied in the order they appear.\nHere’s an example configuration:\nappend_output: - match: source: syscall extra_output: \u0026#34;on CPU %evt.cpu\u0026#34; extra_fields: - home_directory: \u0026#34;${HOME}\u0026#34; - evt.hostname In this example, any rule with the syscall source will have the string on CPU %evt.cpu appended to the end of the default output line. Additionally, extra fields such as home_directory and evt.hostname will be visible in the JSON output under the output_fieldskey but won’t appear in the regular text output. Notably, environment variables are also supported.\nThis option is also available on the command line using the -o flag. For example:\nfalco ... -o \u0026#39;append_output[]={\u0026#34;match\u0026#34;: {\u0026#34;source\u0026#34;: \u0026#34;syscall\u0026#34;}, \u0026#34;extra_fields\u0026#34;: [\u0026#34;evt.hostname\u0026#34;], \u0026#34;extra_output\u0026#34;: \u0026#34;on CPU %evt.cpu\u0026#34;}\u0026#39; The introduction of append_output offers Falco users a flexible way to enrich event outputs, providing deeper visibility and customization tailored to their monitoring needs.\nDynamic Driver Selection in Falco with Helm: Simplifying Multi-Node Deployments Deploying across diverse Kubernetes environments just got easier! When using the official Falco Helm chart and setting driver.kind=auto, the driver loader now intelligently handles the heavy lifting for you.\nHere's how it works: the driver loader will automatically generate a new Falco configuration file and select the correct engine driver based on the specific node Falco is deployed on. This means whether you're using eBPF, kmod, or a modern eBPF driver, Falco will configure itself dynamically depending on the environment.\nIn many Kubernetes clusters, nodes can differ in terms of kernel versions, capabilities, and driver compatibility. With this new auto-selection feature, you can seamlessly deploy different Falco drivers across various nodes within the same cluster. Here’s a simple illustration:\n+-------------------------------------------------------+ | Kubernetes Cluster | | | | +-------------------+ +-------------------+ | | | Node 1 | | Node 2 | | | | | | | | | | Falco (eBPF probe) | | Falco (kmod) | | | +-------------------+ +-------------------+ | | | | +-------------------+ | | | Node 3 | | | | | | | | Falco (modern eBPF)| | | +-------------------+ | +-------------------------------------------------------+ In this example:\nNode 1 is configured with the eBPF probe driver. Node 2 uses the kmod (kernel module) driver. Node 3 leverages the modern eBPF driver for cutting-edge performance. This setup gives you flexibility and ensures that each node in your Kubernetes cluster is running Falco in the most optimized way possible, without manual configuration. Simply set driver.kind=auto in the Helm chart and let Falco do the rest.\nBreaking changes and deprecations ⚠️ This version comes with breaking changes, mostly in the configuration interface\nRemoved command line options and equivalent configuration options We removed the already deprecated options -D, -t, -T and is now possible to achieve the same result through the Falco configuration You con still use the -o command line option:\n-T : use -o rules[].disable.tag=\u0026lt;tag\u0026gt; instead. Turn off any rules with a tag=\u0026lt;tag\u0026gt;. This option can be passed multiple times. This option can not be mixed with -t; -t : use -o rules[].disable.rule=* -o rules[].enable.tag=\u0026lt;tag\u0026gt; instead. Only enable those rules with a tag=\u0026lt;tag\u0026gt;. This option can be passed multiple times; D : use -o rules[].disable.rule=\u0026lt;wildcard-pattern\u0026gt; instead. Turn off any rules with names having the substring . This option can be passed multiple times. You can find more information on breaking changes in the tracking issue.\nNotable Bug Fixes Prometheus Compliant metrics: some metrics have been reworked to follow the prometheus best practices #3319; Fixed ebpf drivers to use the correct memory barrier primitive for ARM64, preventing to read incomplete data from the ring buffers #2067; Fixed an issue where stats messages were written to stdout and could mix with regular Falco event output #3338; fs.path fields now account for dirfd, fixing discrepancies with fd.name #1993; Deprecations In Falco 0.39.0, the --cri and --disable-cri-async options were deprecated, and they will be completely removed in Falco 0.40.0. Moving forward, configuring container runtimes should be done through the falco.yaml file. Below is an example of the new configuration format:\ncontainer_engines: docker: enabled: true cri: enabled: true sockets: [\u0026#34;/run/containerd/containerd.sock\u0026#34;, \u0026#34;/run/crio/crio.sock\u0026#34;, \u0026#34;/run/k3s/containerd/containerd.sock\u0026#34;] disable_async: false podman: enabled: true lxc: enabled: true libvirt_lxc: enabled: true bpm: enabled: true Try it out Interested in trying out the new features? Use the resources below to get started.\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-no-driver (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package What’s next? Falco is more mature with each release. Following its graduation we have published the roadmap for version 1.0.0 which is guiding us in the next steps. For the next release, you can expect more stability, streamlined container images, refinements to our rule syntax, new detections and plugins.\nStay connected Join us on social media and in our weekly community calls! It’s always great to have new members in the community, and we’re looking forward to hearing your feedback and ideas.\nYou can find all the most up-to-date information at https://falco.org/community/.\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.39.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-39-0/"},{"category":"blog","content":"More than 7 years ago, frustrated by the lack of integrations between Falco and third parties, I created Falcosidekick. The tool evolved much more than expected, with the help of dozens of contributors, individuals or for companies, to have now almost 70 different integrations, and more are coming. Its baby brother came few years later, Falcosidekick UI, helping people to visualize in real time the alerts leveraged by Falco and fine tuning their rules.\nA frustation remained after all. With Falco, we have an amazing tool to detect suspicious events in our Linux hosts, VM and Kubernetes clusters, with Falcosidekick, we can easily notify our Dev/Secops, index the alerts in some SIEM, etc. But a last piece was missing: how to react to these events?\nWith the integrations of well known FaaS in Falcosidekick, we started a series of blog posts to show how to create from scratch what we call a \u0026quot;response engine\u0026quot;. All these systems are modular, flexible, robust, but they all require a considerable amount of work from the user, to deal with the Falco payload format, the errors, the retries, the authentication to the API (AWS, Kubernetes Control Plane), the logs, the metrics, etc. Not all users and companies have the skills and/or the budget to maintain such an architecture.\nTo answer these needs, we designed and created Falco Talon. The the first version is officially out!.\nWhat is Falco Talon? Falco Talon is a Response Engine for managing threats in Kubernetes clusters. It enhances the solutions proposed by the Falco community with a no-code tailor-made solution. With easy rules, you can react to events from Falco in milliseconds.\nWhy did we created Falco Talon? Over the years, the Falco community proposed different methods to react to the Falco Events, what we call a response engine.\nAll these methods rely on a 3rd party FaaS (Function as a Service) and come with drawbacks, all actions must be developped by the users to manage:\nThe errors The Falco event format The authentication The K8s SDK complexity The security The upgrades of the dependencies Latency Complexity to manage sequential actions Intrication between the function and the configuration This is why we started to develop a custom solution specifically built for Falco: Falco Talon:\nTailor made for the Falco events Easy to define rules No-code implementation for end-users UX close to Falco with the rules (yaml files with append, override mechanisms) Allow to set up sequential actions to run Structured logs (with a trace id) OTEL/Prometheus Metrics and OTEL Traces What is it good for? React in real-time to the Falco Events Allow fine granularity to match the events to react to Responding to default rules with specific overrides What is it not (yet?) good for? Complex reaction worflows with conditions between the steps Run actions at the host/node level through SSH (like Ansible does) Docs A dedicated website has been created to host the documentation: https://docs.falco-talon.org.\nHow Falco Talon works As the same manner Falcosidekick works, Falco Talon receives the events from Falco by http. All you have to do to connect Falco and Falco Talon is to set in your falco.yaml:\njsonOutput: true jsonIncludeOutputProperty: true httpOutput: enabled: true url: \u0026#34;http://\u0026lt;falco-talon\u0026gt;:2803/\u0026#34; If you already use Falcosidekick to forward your Falco events to the world, an integration is available since Falcosidekick 2.29.0:\ntalon: address: \u0026#34;http://\u0026lt;falco-talon\u0026gt;:2803/\u0026#34; checkcert: false When the events are received by Falco Talon, an internal queue system based on NATS Jetstream is in charge to deduplicate them, to avoid to trigger the same action for the same cause for nothing.\nFalco Talon will then compare the event with the rules created by the user, if an event matches with a rule, a series of actions are sequentially performed. At the end of each step, a notification with the status is sent, and a log is emmited.\nRules The rules are the \u0026quot;core\u0026quot; of Falco Talon as they describe which actions to trigger for which Falco event.\nAll rules are written as yaml file, evaluated in the order they are given to Falco Talon (as arguments or in the config file), with rules specified later in the file overriding the previous ones.\nThe rules are composed of 2 blocks:\nthe action block defines which actionner to use with its parameters, this block can be imported by multiple rules (like the macros can be used in the Falco rules) the rule block defines the criterias to match to trigger the actions The criterias to match the event with the actions can use all elements that compose a Falco event JSON payload:\nthe Falco rule name the priority the tags the output fields Examples When Falco Talon receives an event triggered by the Falco rule named Terminal shell in container, and this event doesn't concern the kubernetes namespaces kube-system and falco, then the related pod is labeled suspicious: true\n- action: Label Pod as Suspicious description: \u0026#34;Add the label suspicious=true\u0026#34; actionner: \u0026#34;kubernetes:label\u0026#34; parameters: labels: suspicious: \u0026#34;true\u0026#34; - rule: Terminal shell in container description: \u0026gt; Label the pod outside kube-system and falco namespaces if a shell is started inside match: rules: - Terminal shell in container output_fields: - k8s.ns.name!=kube-system, k8s.ns.name!=falco actions: - action: Label Pod as Suspicious The action block are useful but not mandatory, the same result can be done by specifying the action in the rule block directly:\n- rule: Terminal shell in container match: rules: - Terminal shell in container output_fields: - k8s.ns.name!=kube-system, k8s.ns.name!=falco actions: - action: Label Pod as Suspicious actionner: \u0026#34;kubernetes:label\u0026#34; parameters: labels: suspicious: \u0026#34;true\u0026#34; Actionners The actionners are on-catalog actions you can use. You just have to specify which one you want use to use, its parameters, and Falco Talon will manage for you all the complexity. This is how we created a no code response engine.\nWithin this first version, we tried to integrate as much useful actionners as possible, which allow you to manage a large variety of situations and reactions in Kubernetes.\nThe available actionners are:\nkubernetes:terminate kubernetes:label kubernetes:networkpolicy kubernetes:exec kubernetes:script kubernetes:log kubernetes:delete kubernetes:drain kubernetes:download kubernetes:tcpdump aws:lambda calico:networkpolicy cilium:networkpolicy To know more about what the actionners do, what parameters they require, you can read on docs/actionners.\nYou can notice all actionners names are composed of 2 elements x:y, the first element is the category of the actionner. All actionners in the same category share the same client, it avoid to have multi inits and instances.\nOutputs Some actionners require an output, an output is a target for the artifact created by the actionner, for example for the file retrieved by kubernetes:download or the .pcap created by kubernetes:tcpdump.\n3 outputs are available today:\nlocal:file (only useful for local tests) aws:s3 minio:s3 The list of the available outputs can be found on docs/outputs.\nExample - rule: Redirect STDOUT/STDIN to Network Connection in Container match: rules: - Redirect STDOUT/STDIN to Network Connection in Container actions: - action: Run tcpdump for 5s actionner: \u0026#34;kubernetes:tcpdump\u0026#34; parameters: snaplen: 512 duration: 5 output: target: \u0026#34;aws:s3\u0026#34; parameters: bucket: \u0026lt;my-bucket\u0026gt; prefix: /tcpdump/ region: us-east-1 Notifiers Even we're talking about a \u0026quot;response engine\u0026quot;, a framework to automatically react to some events, we still want (we humans), to be noticed of what's happening or keep traces of the performed actions.\nApart from logs output to stdout, some notifiers can be used to forward action results:\nelasticsearch k8sevents loki slack smtp webhook The list of the available notifiers can be found on docs/notifiers.\nExamples k8sevents:\naction: kubernetes:tcpdumpthought, apiVersion: v1 eventTime: \u0026#34;2024-09-05T12:52:10.819462Z\u0026#34; firstTimestamp: null involvedObject: kind: Pod namespace: default kind: Event lastTimestamp: null message: | Status: success Message: action Rule: Redirect STDOUT/STDIN to Network Connection in Container Action: Run tcpdump for 5s Actionner: kubernetes:tcpdump Event: Redirect STDOUT/STDIN to Network Connection in Container Namespace: default Pod: cncf-55696bc998-5xjcb Output: a tcpdump \u0026#34;tcpdump.pcap\u0026#34; has been created TraceID: c954bd8b3391a08f23079552fdd639f3 metadata: creationTimestamp: \u0026#34;2024-09-05T12:52:10Z\u0026#34; generateName: falco-talon- name: falco-talon-zgxfm namespace: default resourceVersion: \u0026#34;115862544\u0026#34; uid: 3b4bd17f-ed1a-4693-bfd7-d10f674a8008 reason: falco-talon:action:kubernetes:tcpdump:success reportingComponent: falcosecurity.org/falco-talon reportingInstance: falco-talon source: component: falco-talon type: Normal slack:\nA tool designed for the production I spent 10 years of my career as a DevOps/SRE, managing traditional and cloud infrastructures, I know how painful it is to manage systems not well designed for the runtime. This is why we tried from the beginning to create a tool easy to rule all along it lifecycle.\nA CLI to validate the rules As it is for the Falco rules, the best way to manage the lifecycle of the rules for Falco Talon is to follow the GitOps principles. This requires to set up a validation of their syntax as step in the CI.\nThe Falco Talon binary can also be used as a CLI, allowing to perfom tasks on the rules, like checking their validity or printing their results after the merges/overrides of several files:\n$ falco-talon rules check --help Check Falco Talon Rules file Usage: falco-talon rules check [flags] Flags: -h, --help help for check Global Flags: -c, --config string Falco Talon Config File (default \u0026#34;/etc/falco-talon/config.yaml\u0026#34;) -r, --rules stringArray Falco Talon Rules File (default [/etc/falco-talon/rules.yaml]) Examples With a valid rules file:\n$ falco-talon rules check -c ./config.yaml -r ./rules.yaml 2024-09-05T16:42:28+02:00 INF rules result=\u0026#34;rules file valid\u0026#34; With an invalid rules file:\n$ falco-talon rules check -c ./config.yaml -r ./rules.yaml 2024-09-05T16:44:01+02:00 ERR rules error=\u0026#34;unknown actionner\u0026#34; action=\u0026#34;Label Pod as Suspicious\u0026#34; actionner=foor:bar rule=\u0026#34;Terminal shell in container\u0026#34; 2024-09-05T16:44:01+02:00 FTL rules error=\u0026#34;invalid rules\u0026#34; exit status 1 Structured Logs The logs, whatever the component emitting them, keep always the same structure and contain a trace_id field, allowing to follow the workflow performed by Falco Talon.\nThe value of trace_id is also used to create the TraceId the OTEL Traces, by using a log backend like Loki, it becomes easy to correlate the traces with the logs in the same UI, like Grafana.\nThe CLI contains more features, take a look at them on docs /installation_usage/usage.\nExample Each step is clearly identified by the tag after the log level:\n2024-09-05T14:52:03+02:00 INF event event=\u0026#34;Redirect STDOUT/STDIN to Network Connection in Container\u0026#34; output=\u0026lt;truncated\u0026gt; priority=Critical source=syscall trace_id=c954bd8b3391a08f23079552fdd639f3 2024-09-05T14:52:03+02:00 INF match event=\u0026#34;Redirect STDOUT/STDIN to Network Connection in Container\u0026#34; output=\u0026lt;truncated\u0026gt; priority=Critical rule=\u0026#34;Reverse shell detected\u0026#34; source=syscall trace_id=c954bd8b3391a08f23079552fdd639f3 2024-09-05T14:52:10+02:00 INF action action=\u0026#34;Run tcpdump for 5s\u0026#34; actionner=kubernetes:tcpdump event=test namespace=default output=\u0026#34;a tcpdump \u0026#39;tcpdump.pcap\u0026#39; has been created\u0026#34; pod=cncf-55696bc998-5xjcb rule=\u0026#34;Reverse shell detected\u0026#34; status=success trace_id=c954bd8b3391a08f23079552fdd639f3 2024-09-05T14:52:10+02:00 INF notification action=\u0026#34;Run tcpdump for 5s\u0026#34; actionner=kubernetes:tcpdump notifier=k8sevents rule=\u0026#34;Reverse shell detected\u0026#34; stage=action status=success trace_id=c954bd8b3391a08f23079552fdd639f3 2024-09-05T14:52:11+02:00 INF output action=\u0026#34;Run tcpdump for 5s\u0026#34; bucket=xxxxx category=aws file=tcpdump.pcap key=2024-09-05T14-52-10Z_default_cncf-55696bc998-5xjcb_tcpdump.pcap output=\u0026#34;the file \u0026#39;tcpdump.pcap\u0026#39; has been uploaded as the key \u0026#39;tcpdump/2024-09-05T14-52-10Z_default_cncf-55696bc998-5xjcb_tcpdump.pcap\u0026#39; to the bucket \u0026#39;xxxxx\u0026#39;\u0026#34; output_target=aws:s3 prefix=tcpdump/ region=us-east-1 status=success trace_id=c954bd8b3391a08f23079552fdd639f3 2024-09-05T14:52:11+02:00 INF notification action=\u0026#34;Run tcpdump for 5s\u0026#34; actionner=kubernetes:tcpdump notifier=k8sevents output_target=aws:s3 rule=\u0026#34;Reverse shell detected\u0026#34; stage=output status=success trace_id=c954bd8b3391a08f23079552fdd639f3 Metrics Falco Talon exposes the traditional /metrics endpoint with metrics in the Prometheus format.\nTo keep a consistency, all metrics related to Falco Talon itself are prefixed with falcosecurity_falco_talon_, it follows the same convention used by Falco for its metrics.\nFor people interested by the metrics in the OTEL format, it's also available, see docs installation_usage/metrics\nExample # HELP action_total number of actions # TYPE action_total counter falcosecurity_falco_talon_action_total{action=\u0026#34;Disable outbound connections\u0026#34;,actionner=\u0026#34;kubernetes:networkpolicy\u0026#34;,event=\u0026#34;Test logs\u0026#34;,namespace=\u0026#34;falco\u0026#34;,otel_scope_name=\u0026#34;github.com/Falco-Talon/falco-talon\u0026#34;,otel_scope_version=\u0026#34;devel\u0026#34;,pod=\u0026#34;falco-5b7kc\u0026#34;,rule=\u0026#34;Suspicious outbound connection\u0026#34;,status=\u0026#34;failure\u0026#34;} 6 falcosecurity_falco_talon_action_total{action=\u0026#34;Terminate Pod\u0026#34;,actionner=\u0026#34;kubernetes:terminate\u0026#34;,event=\u0026#34;Test logs\u0026#34;,namespace=\u0026#34;falco\u0026#34;,otel_scope_name=\u0026#34;github.com/Falco-Talon/falco-talon\u0026#34;,otel_scope_version=\u0026#34;devel\u0026#34;,pod=\u0026#34;falco-5b7kc\u0026#34;,rule=\u0026#34;Suspicious outbound connection\u0026#34;,status=\u0026#34;failure\u0026#34;} 6 # HELP event_total number of received events # TYPE event_total counter falcosecurity_falco_talon_event_total{event=\u0026#34;Unexpected outbound connection destination\u0026#34;,otel_scope_name=\u0026#34;github.com/Falco-Talon/falco-talon\u0026#34;,otel_scope_version=\u0026#34;devel\u0026#34;,priority=\u0026#34;Critical\u0026#34;,source=\u0026#34;syscalls\u0026#34;} 2 # HELP match_total number of matched events # TYPE match_total counter falcosecurity_falco_talon_match_total{event=\u0026#34;Unexpected outbound connection destination\u0026#34;,otel_scope_name=\u0026#34;github.com/Falco-Talon/falco-talon\u0026#34;,otel_scope_version=\u0026#34;devel\u0026#34;,priority=\u0026#34;Critical\u0026#34;,rule=\u0026#34;Suspicious outbound connection\u0026#34;,source=\u0026#34;syscalls\u0026#34;} 2 OTEL Traces We know following logs can be not really convenient, and they may lack of useful informations. You can therefore enable the emits of Traces in the OTEL format. All backends accepting this format can be used to store and visualize them.\nTo know how to set up the traces, see docs installation_usage/traces.\nExamples In Grafana with Tempo:\nIn Jaeger:\nInstallation The easiest way, for now, to deploy Falco Talon is to use the Helm chart included in the repo.\nwith Helm Since version 0.2.0, chart has been moved under the official falcosecurity/charts repository\nThe procedure to install the v0.1.0 of Falco Talon is:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update falcosecurity helm upgrade --install falco-talon falcosecurity/falco-talon Shoutout I would like to shoutout some persons without the project would have been possible:\nDan Papandrea who thought about the first specs of the project with me and found the name Falco Talon Igor Eulalio who develops Falco Talon with me, introduced amazing features like the traces, and injected so much energy in the project Rachid Zarouali, the tester #1, a lot of features came from his ideas and feedbacks, he's also always a pleasure to present a talk about Falco Talon with him Nigel Douglas who tests and promotes Falco Talon with talks and blog posts since the alpha stages Carlos Tadeu Panato Júnior the magician of the CI, who still continue to manage the upgrade of the dependencies What's next? This first release, the v0.1.0, is just GA and it's the beginning of the journey. All your feebacks and ideas are welcome, this project has for DNA to improve the security of the Kubernetes clusters by answering real needs and usages.\nThe next big step to achieve is to join officially the falcosecurity organization. An issue has been created in the evolution repo to do so. Don't hesitate to vote for 🙏!\nThomas\nTo go further:\nGitHub repo of the Falco Talon project: https://github.com/falco-talon/falco-talon Official docs of Falco Talon: https://docs.falco-talon.org/ A record of a talk (by Rachid and Thomas) in French to introduce Falco Talon: https://www.youtube.com/watch?v=Mx28fhyKX7Q ","summary":"","tags":["Talon","Release"],"title":"Introducing Falco Talon v0.1.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-talon-v0-1-0/"},{"category":"blog","content":"Today we announce the release of Falco 0.38.2 🦅!\nFixes Falco's 0.38.2 is a patch release that includes the most important bugfixes addressed this summer ☀️:\nFixed a crash when using transformer operators (e.g. tolower()) with a parameter that evaluates to an empty string Fixed a bug and a regression that could result in incorrect comparison between ipv4 addresses and ipv6 subnets and vice versa Fixed an issue that could result in missing exe_upper_layer flag Fixed kernel module build for Linux 6.10 Fixed a bug that may result in kernel module crashes on recent versions of RHEL 9 Added additional logging to better troubleshoot hard to reproduce issues like \u0026quot;could not parse param ... for event ... of type ...: expected length X, found Y\u0026quot; This patch also introduces a small change with the format of the new experimental Prometheus metrics to make them easier to use. Metrics are now distinguished by the file_name or rule_name labels, in line with Prometheus best practices and supporting groupBy queries.\nThanks to everyone in the community for helping us with spotting these annoying bugs and improving Falco every day 🐛! You make Falco successful 🦅!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nTry it! 🏎️ As usual, in case you just want to try out the stable Falco 0.38.2, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Prefer to use a container image? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader Let's meet 🤝 We meet every Wednesday in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nEnjoy 😎,\nLuca\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.38.2","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-38-2/"},{"category":"blog","content":"Hello Falco community, I'm Kiriti, a current GSoC mentee under Falco Security. I have been working diligently to improve the testing and benchmarking capabilities of Falco’s event-generator project. Now that we've reached the midterm of GSoC, I'm eager to share the journey so far. In this blog, I'll delve into the details of my contributions, particularly focusing on two key PRs that have been merged, and outline my plans for the remainder of the program.\nMy Project: Enhancing Falco's Event-Generator The event-generator is a vital utility within the Falco ecosystem, designed to test Falco's detection capabilities. My Google Summer of Code project focuses on upgrading the event-generator to enhance its testing and benchmarking capabilities, reliability, and consistency. Additionally, I am developing new Continuous Integration (CI) pipelines based on the upgraded event-generator. The ultimate goal is to evolve the event-generator into the standard tool for systematically assessing the correctness and performance of Falco’s threat detection capabilities during every release and development cycle.\nMy Journey So Far: Before being selected for GSoC, I contributed to the event-generator repository. I am grateful to Leonardo Grasso and Federico Di Pierro, who played a vital role in getting my PRs merged during the pre-GSoC contribution phase. These contributions helped me understand the event-generator codebase. I am also thankful to my mentors, Jason Dellaluce and Aldo Lacuku, for selecting me as a GSoC mentee. I will share my complete story of getting selected to GSoC in future.\nAfter my selection, Jason, Aldo, and I collectively designed a plan to enhance the event-generator. The community bonding period was crucial in designing and understanding the implementation plan. You can view our idea here, which we will implement during this GSoC period.\nOnce the coding period began, we managed to merge two key PRs before the midterm. These PRs partially added support for testing Falco rules using declarative YAML files in the event-generator. We also added support for a container runner, which spawns a new container and runs the specified steps inside it. This is particularly useful for testing Falco rules that trigger when certain events are executed inside a container.\nDetailed Look at the Merged PRs: PR1: Add support for declarative yaml file testing what's new added in this PR?: Added a new sub command for run command called declarative:\nevent-generator run declarative [yaml-file-path] Implemented a helper function that parses the YAML file and returns the content in a specified format. The function signature is as follows:\nfunc parseYamlFile(filepath string) (declarative.Tests, error) Each yaml file structure should be in the following format\ntype SyscallStep struct { Syscall string `yaml:\u0026#34;syscall\u0026#34;` Args map[string]string `yaml:\u0026#34;args\u0026#34;` } type Test struct { Rule string `yaml:\u0026#34;rule\u0026#34;` Runner string `yaml:\u0026#34;runner\u0026#34;` Before string `yaml:\u0026#34;before\u0026#34;` Steps []SyscallStep `yaml:\u0026#34;steps\u0026#34;` After string `yaml:\u0026#34;after\u0026#34;` } type Tests struct { Tests []Test `yaml:\u0026#34;tests\u0026#34;` } Implemented a host runner A host runner is represented with the following interface\ntype Runner interface { Setup(beforeScript string) error ExecuteStep(step SyscallStep) error Cleanup(afterScript string) error } The Setup method runs a shell script (beforeScript) before executing the specified steps using the ExecuteStep method. The Cleanup method runs a shell script (afterScript) after executing the steps.\nThe ExecuteStep method makes some syscalls specified in the YAML file using helper functions. For example, when a write syscall is used in the YAML file steps, it runs the following write syscall helper function:\nAdded helper for making a write syscall: The function signature is as follows\nfunc WriteSyscall(filePath string, content string) error PR2: Add container runner support To implement a container runner, we needed the ability to spawn a container and execute the events inside it. We achieved this using the Docker GO SDK.\nThe container runner interface is similar to the host runner, with two new parameters: ContainerId and Image.\nThe Setup method spawns a container with the given image name, saves the ContainerId, and also executes the beforeScript. The Cleanup method removes the container after executing the steps.\ntype Runner interface { ContainerId string Image string Setup(beforeScript string) error ExecuteStep(step SyscallStep) error Cleanup(afterScript string) error } Future Work: The upcoming tasks we are going to handle are:\nImplement ExecuteStep method in container runner Add support/ helper functions to make various syscalls Improve benchmarking capabilities of the event-generator Integrate the event-generator in falco ci pipeline Conclusion: Participating in GSoC with Falco Security has been an incredible journey so far. Enhancing the event-generator has provided me with invaluable insights into cloud-native runtime security and the complexities of Falco’s detection capabilities. The support and guidance from my mentors, Jason and Aldo, through our weekly 1:1 calls, have been crucial in overcoming challenges and driving the project forward.\nAs I look ahead, I am excited about the upcoming tasks and the potential impact our improvements will have on the Falco ecosystem. I eagerly anticipate continuing this journey and sharing more updates on our progress. Thank you for following along!\n","summary":"","tags":["Gsoc","midterm","Mentorship"],"title":"Halfway Through GSoC 2024: My Progress and Plans with Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/gsoc-2024-midterm/"},{"category":"blog","content":"Talos Linux is an OS designed for Kubernetes, with in mind to be secure, immutable and minimal. It offers a solution for having secure nodes for your Kubernetes cluster. Running Falco on them requires some configurations we'll see in this blog post. The good news is everything is available to collect the syscalls with eBPF and also the audit logs from the Kubernetes control plane.\nIn this tutorial we'll use a local \u0026lt;code\u0026gt;Talos\u0026lt;/code\u0026gt; cluster created with Docker containers for convenience, adapt the configurations to your own context. Requirements For this tutorial, you'll need several tools installed:\nDocker Helm talosctl kubectl Set up the Talos cluster We'll start with a 2 workers cluster:\ntalosctl cluster create --workers 2 --wait-timeout 5m After a few minutes, your containers and so your cluster should be up and running. You can check the status with:\ntalosctl cluster show --nodes 10.5.0.2,10.5.0.3,10.5.0.4 Output:\nPROVISIONER docker NAME talos-default NETWORK NAME talos-default NETWORK CIDR 10.5.0.0/24 NETWORK GATEWAY NETWORK MTU 1500 NODES: NAME TYPE IP CPU RAM DISK talos-default-controlplane-1 controlplane 10.5.0.2 - - - talos-default-worker-1 worker 10.5.0.3 - - - talos-default-worker-2 worker 10.5.0.4 - - - Get the kubeconfig The talosctl CLI allows to easily set up your kubeconfig file for managing the apps in your fresh new cluster:\ntalosctl kubeconfig -n 10.5.0.2 -f Check you have access to the cluster:\nkubectl cluster-info Output:\nKubernetes control plane is running at https://10.5.0.2:6443 CoreDNS is running at https://10.5.0.2:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use \u0026#39;kubectl cluster-info dump\u0026#39;. Patch the cluster When you deploy Falco with Helm in a Kubernetes cluster, an initContainer is bootstrapped to inject the eBPF probe into the kernel of each node. This behavior requires some privileges but Talos, designed to be secured, doesn't allow that by default. It's possible anyway by patching the nodes.\nCreate this patch.yaml file:\ncluster: apiServer: admissionControl: - name: PodSecurity configuration: exemptions: namespaces: - falco As you can see, we allow the pods in the namespace \u0026lt;code\u0026gt;falco\u0026lt;/code\u0026gt; to use \u0026lt;code\u0026gt;PodSecurity\u0026lt;/code\u0026gt; settings. And now patch the cluster:\ntalosctl patch machineconfig --patch @patch.yaml --nodes 10.5.0.2 Output:\npatched MachineConfigs.config.talos.dev/v1alpha1 at the node 10.5.0.2 Applied configuration without a reboot Install Falco We'll use Helm to deploy Falco.\nInstall the Helm registry for the Falco chart: helm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update Create the values.yaml file: cat \u0026lt;\u0026lt; EOF \u0026gt; values.yaml driver: kind: modern_ebpf tty: true falcosidekick: enabled: true replicaCount: 1 webui: enabled: true replicaCount: 1 redis: storageEnabled: false service: type: NodePort port: 2802 targetPort: 2802 nodePort: 30128 falcoctl: artifact: install: enabled: true follow: enabled: true config: artifact: install: refs: [falco-rules:latest, falco-incubating-rules:latest, k8saudit-rules:latest] follow: refs: [falco-rules:latest, falco-incubating-rules:latest, k8saudit-rules:latest] services: - name: k8saudit-webhook type: ClusterIP ports: - port: 9765 targetPort: 9765 protocol: TCP name: http falco: rules_files: - /etc/falco/falco_rules.yaml - /etc/falco/falco-incubating_rules.yaml - /etc/falco/k8s_audit_rules.yaml - /etc/falco/rules.d plugins: - name: k8saudit library_path: libk8saudit.so init_config: \u0026#34;\u0026#34; open_params: \u0026#34;http://:9765/k8s-audit\u0026#34; - name: json library_path: libjson.so init_config: \u0026#34;\u0026#34; load_plugins: [k8saudit, json] EOF Deploy Falco: helm upgrade -i falco falcosecurity/falco -n falco --create-namespace -f values.yaml Follow the deployment: kubectl get pods -w -n falco Before moving on, let's take time to explain why some of these values.\ndriver: kind: modern_ebpf tty: true We use the modern_epbf probe to collec the syscall events. tty: true allows to get the alerts in the stdout immediatly, without any buffering. falcosidekick: enabled: true replicaCount: 1 webui: enabled: true replicaCount: 1 redis: storageEnabled: false service: type: NodePort port: 2802 targetPort: 2802 nodePort: 30128 We install Falcosidekick and its UI. All settings for the forwarding of the events between Falco and Falcosidekick are managed by the Helm chart. As it's local cluster, we set the replicaCounts to 1, it loses the HA but save resources. The UI will be exposed directly by the nodes on the port 30128, very convenient for a local cluster, prefer an ingress or just a port-forward for production. falcoctl: artifact: install: enabled: true follow: enabled: true config: artifact: install: refs: [falco-rules:latest, falco-incubating-rules:latest, k8saudit-rules:latest] follow: refs: [falco-rules:latest, falco-incubating-rules:latest, k8saudit-rules:latest] falcoctl controls which plugins and rules to install and follow. We install the stable and incubating rules for Falco We install and follow the rules for the Kubernetes audit logs, the relevant plugins k8saudit and json will be automatically installed by falcoctl. services: - name: k8saudit-webhook type: ClusterIP ports: - port: 9765 targetPort: 9765 protocol: TCP name: http The k8saudit plugin requires to create a Service listen the incoming events from the control plane.\nfalco: rules_files: - /etc/falco/falco_rules.yaml - /etc/falco/falco-incubating_rules.yaml - /etc/falco/k8s_audit_rules.yaml - /etc/falco/rules.d plugins: - name: k8saudit library_path: libk8saudit.so init_config: \u0026#34;\u0026#34; open_params: \u0026#34;http://:9765/k8s-audit\u0026#34; - name: json library_path: libjson.so init_config: \u0026#34;\u0026#34; load_plugins: [k8saudit, json] We load the rules for the syscalls and for the audit logs. We load the plugins and their config. The k8saudit plugin will listen on the same port than configured in the services section. Forward the audit logs to Falco In a classic context, the control plane is configured to send its audit logs to an endpoint, like the k8saudit plugin. With Talos, it's not yet possible to configure this endpoint, but fortunately for us, these audit logs are written as files in the /var/log/audit/kube/ folder of the master nodes.\nWe'll use Fluent Bit to parse these files and forward them to the k8saudit plugin.\nInstall the Helm registry for the Fluent Bit chart: helm repo add fluent https://fluent.github.io/helm-charts helm repo update Create the values.yaml file: cat \u0026lt;\u0026lt; EOF \u0026gt; values.yaml podAnnotations: fluentbit.io/exclude: \u0026#39;true\u0026#39; daemonSetVolumes: - name: varlog hostPath: path: /var/log daemonSetVolumeMounts: - name: varlog mountPath: /var/log tolerations: - operator: Exists effect: NoSchedule nodeSelector: node-role.kubernetes.io/control-plane: \u0026#34;\u0026#34; config: service: | [SERVICE] Flush 5 Daemon Off Log_Level warn HTTP_Server On HTTP_Listen 0.0.0.0 HTTP_Port 2020 Health_Check On Parsers_File /fluent-bit/etc/parsers.conf Parsers_File /fluent-bit/etc/conf/custom_parsers.conf inputs: | [INPUT] Name tail Alias audit Path /var/log/audit/kube/*.log Parser audit Tag audit.* Ignore_older true customParsers: | [PARSER] Name audit Format json Time_Key requestReceivedTimestamp Time_Format %Y-%m-%dT%H:%M:%S.%L%z outputs: | [OUTPUT] Name http Alias http Match * Host falco-k8saudit-webhook.falco.svc.cluster.local Port 9765 URI /k8s-audit Format json EOF Deploy Fluent Bit: helm upgrade -i fluent-bit fluent/fluent-bit -n kube-system -f values.yaml To be allowed to mount the folder with the logs, we install \u0026lt;code\u0026gt;Fluent Bit\u0026lt;/code\u0026gt; in the namespace \u0026lt;code\u0026gt;kube-system\u0026lt;/code\u0026gt;. Follow the deployment: kubectl get pods -n kube-system -w -l app.kubernetes.io/name=fluent-bit Some explanations of the values.yaml.\ndaemonSetVolumes: - name: varlog hostPath: path: /var/log daemonSetVolumeMounts: - name: varlog mountPath: /var/log The host folder with the logs is mounted inside the Fluent Bit pod.\ntolerations: - operator: Exists effect: NoSchedule nodeSelector: node-role.kubernetes.io/control-plane: \u0026#34;\u0026#34; These settings are there to deploy Fluent Bit on the master nodes only.\nconfig: inputs: | [INPUT] Name tail Alias audit Path /var/log/audit/kube/*.log Parser audit Tag audit.* Ignore_older true Fluent Bit will parse the files *.logs from the folder /var/log/audit/kube/.\nconfig: outputs: | [OUTPUT] Name http Alias http Match * Host falco-k8saudit-webhook.falco.svc.cluster.local Port 9765 URI /k8s-audit Format json The logs are forwarded to the endpoint falco-k8saudit-webhook.falco.svc.cluster.local:9765/k8s-audit, which is listened by the k8saudit plugin.\nVisalize the alerts Everything should be set up and running from now. You can access to the Falcosidekick-UI by the URL http://10.5.0.2:30128.\nThe default credentials are admin/admin.\nConclusion Talos Linux is a more and more famous solution for creating resilient and secure Kubernetes clusters, but the trust doesn't exclude control. Mixing Talos and Falco makes you gain a step upper in term of security for your applications. Thanks to our modern eBPF probe and our k8saudit plugin, you can see how easy and quick it is to install Falco in Talos and start to observe what's happening.\nThanks to Quentin Joly for his blog post about Talos which helped me a lot to write this one.\nGet started in Falco.org Check out the Falcosidekick project on GitHub. Check out the Falcosidekick UI project on GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falco","eBPF"],"title":"Deploy Falco on a Talos cluster","url":"https://v0-43--falcosecurity.netlify.app/blog/deploy-falco-talos-cluster/"},{"category":"blog","content":"Almost 1 year without a release of Falcosidekick, but version 2.29.0 is finally here. Thanks to all contributors for their patience, you made amazing contributions and we're happy to finally have them available for all users.\nLike for every releases, a small recap about its adoption. Falcosidekick continues to be adopted, even if the rate is not as high as before, but we're sure it will explode once again with this new fresh version.\nOnce more, Falcosidekick expands Falco's integrability with a lot of new outputs. That and the introduction of many new features has been possible thanks to the hard work of the community. You can find a comprehensive list of these in the changelog.\nNew outputs More and more systems are integrated as outputs in Falcosidekick, more and more often directly by the companies themselves and not their end users. It shows Falco and Falcosidekick are seen as major components in the security fields, and trusted as de facto standards.\nDynatrace Mario Kahlhofer, aka @blu3r4y, from Dynatrace, integrated the well known observability and security platform he works for. You can even read his blog post about, to discover how to correlate the Falco events with their APM agent events.\nSumologic Carlo Mencarelli, aka @mencarellic, did the exporter of the Falco events to Sumologic, the SaaS platform for your logs.\nOTLP Traces It started as an internal hackaton at Grafana Labs and became a real integration thanks to JuanJo Ciarlante (@jjo). You can now export the Falco event as traces, to have an automatic correlation between the detected events.\n[!WARNING] It works only for the syscall related events.\nQuickwit After a demo of Falco at a CNCF Meetup, the Quickwit team wanted to add their product as a new output for Falcosidekick, and they did it. You can now easily index your Falco events in their search engine thanks to the work of Idriss Neumann (@idrissneumann).\nFalco Talon New born in the Falco ecosystem, trying to complete the last missing piece: the reaction. You can now forward the Falco events to Falco Talon, a tailor made no-code response engine for Falco. The project is still in alpha stage, but moves quickly. Stay tuned.\nNew features Aside from new outputs, we introduced very important and useful new features. Let's do a recap of them.\nRevamp of the Policy Report output The Policy Report feature in Kubernetes evolved since its integration in Falcosidekick, it was the time to do some clean up. The report now contains more information, and their displays in the Policy Reporter UI is better.\nNew outputFieldFormat setting Some systems perform deduplication of the events, for example the on-call platforms. They use the content of the output to do so, but the current format starting with a timestamp prevents the process to run as expected. A new setting outputFieldFormat is now available allows to \u0026quot;format\u0026quot; the output field of the Falco payload before forwarding it to the outputs.\nThe default format received from Falco is : \u0026lt;timestamp\u0026gt;: \u0026lt;priority\u0026gt; \u0026lt;output\u0026gt; which corresponds to this:\n14:37:27.505989596: Warning Detected ptrace PTRACE_ATTACH attempt (proc_pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info) By removing the \u0026lt;timestamp\u0026gt; and \u0026lt;priority\u0026gt;, you get:\nDetected ptrace PTRACE_ATTACH attempt (proc_pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info) If you use the settings customFields and templatedFields of Falcosidekick to inject new elements in the output_fields, it's also possible to have them in the output with the tokens \u0026lt;custom_fields\u0026gt; and \u0026lt;templated_fields\u0026gt;.\nAlternative endpoints for AWS S3 Some projects like Minio are S3-compliant, you can now use them as target for the AWS S3 output by changing the endpoint to use. Thanks to @gysel for this feature.\nSplit of the docs The main README of the project became really huge over the years, with all those available outputs. We did a big refactor and you can now find one file per output, with more details about the configuration, the default values and some tips. The docs are here, and any help is welcome to make them even better.\nFixes The contributors fixed several bugs, here's a non exhaustive list of the more important ones:\nFix missing root CA for the Kafka output (thanks to @claviola) Fix bug with the extension source in the CloudEvent output Fix panics in the Prometheus output when hostname field is missing Fix locks in the Loki output (thanks to @bsod90) Fix mTLS client verification failures due to missing ClientCAs (thanks to @jgmartinez) Fix wrong env vars for pagerduty output Remove hard settings for usernames in Mattermost and Rocketchat Fix multi lines json in the error lines (thanks to @idrissneumann) Fix duplicated custom headers in clients Fix the labels for the AlertManager output (thanks to @Umaaz) Conclusion You can find the full changelog here.\nThe respective Helm charts are already updated and allow you to test by yourself all these great new features. Just issue the helm repo update; helm upgrade --reuse-values -n falco command to do so.\nOnce again, thanks to all the adopters and contributors who helped and contributed to this project all these years. We would never have reached this success without you.\nGet started in Falco.org Check out the Falcosidekick project on GitHub. Check out the Falco Talon project docs. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Release"],"title":"Falcosidekick 2.29.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-2-29-0/"},{"category":"blog","content":"Today we announce the release of Falco 0.38.1 🦅!\nFixes Falco's 0.38.1 is a patch release aimed at addressing a few important bugs. It includes the following fixes:\nA Falco crash while running with plugins and metrics enabled has been solved (https://github.com/falcosecurity/falco/issues/3229) Falco -p output format option can now be passed to plugin events while -pc and -pk can only be used for syscall sources. Fixes an issue that could result in Falco exiting with LOAD_ERR_COMPILE_OUTPUT on startup with k8s clusters that had -pk and audit enabled (https://github.com/falcosecurity/falco/pull/3239) Fixed an issue that could prevent the integer compare operators \u0026lt;, \u0026lt;=, \u0026gt;, \u0026gt;= in rules from working properly (https://github.com/falcosecurity/falco/issues/3245) Ignore NSS user and group entries while loading users and groups (https://github.com/falcosecurity/libs/pull/1909) Issues related to the new metric-related plugins API (https://github.com/falcosecurity/libs/pull/1885). Plugin API was also bumped to 3.6.0. Plugin metrics are now enabled in Falco (https://github.com/falcosecurity/falco/pull/3228). Note that plugin must make use of the new metrics-related API to expose metrics. Libs were updated to 0.17.2 Thanks to everyone in the community for helping us in spotting these annoying bugs 🐛! You make Falco successful 🦅!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nTry it! 🏎️ As usual, in case you just want to try out the stable Falco 0.38.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Prefer to use a container image? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader Let's meet 🤝 We meet every Wednesday in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nFederico\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.38.1","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-38-1/"},{"category":"blog","content":"Dear Falco Community, today we are happy to announce the release of Falco 0.38.0! This is the first Falco release since its graduation within the CNCF, and, as usual, brings many improvements and features alongside some pretty big changes in its configuration mechanism.\nThis release brings an easier to use mechanism to install and configure your drivers, new rule language features, better support for Falco metrics and many more improvements.\nDuring this release cycle, we merged more than 100 PRs on Falco and more than 180 PRs for libs and drivers, version 0.17.0 and version 7.2.0 respectively. Thank you to our maintainers and contributors, as this would not happen without your support and dedication!\nTo learn all about these changes, read on!\nWhat’s new? TL;DR Key features:\nNew capabilities in falcoctl to automatically select the best driver for your system and make it easier to install The Falco configuration file can now be split into multiple files to make it more manageable Rule selection from configuration file or command line Field transformers and value comparison Prometheus metrics support Plugin API improvements This release also comes with breaking changes that you should be aware of before upgrading.\nMajor features and improvements The 0.38.0 release contains a number of feature and UX improvements, here are list of some of the key new capabilities.\nDriver loader magic ✨ If we could pick the most common issue that we've heard from adopters and we experienced first hand is the fact that sometimes we all struggle with installing and upgrading Falco drivers. The Falco team has been tirelessly working for years to improve the installation experience and Linux kernel compatibility with massive changes such as the introduction of the new CO-RE eBPF probe and most recently the complete rewrite of our driver loading component, integrated in falcoctl. With this new version of falcoctl, integrated in Falco 0.38.0, our loading tool will automatically detect your system and pick the most compatible driver without any intervention; on recent kernel versions this is likely the modern eBPF probe. As you probably know, the modern probe does not require any extra driver download or compilation, making it load almost instantly. Of course, the tool also allows to select the preferred driver if the automatic choice is not optimal for your use case. On top of that, our driver loader tool can now automatically download kernel headers for many distributions supported by driverkit so in many cases you will be able to install even the kernel module without having to install kernel headers first. Read more about how to configure this functionality in the installation documentation page.\nOrganize your Falco configuration files 🗃️ Our falco.yaml configuration file gains more options, fine tuning configuration flags and feature selection for every release; in fact, they are so many that some people would like to better organize them in separate configuration files which can also be kept across Falco upgrades. Starting from this release you can add list of files or directory to the config_files configuration entry, which comes populated with the /etc/falco/config.d/ directory by default. Any additional file is read in order and can override settings in falco.yaml. Read more in the configuration options section of the documentation.\nChoose which rules to load at runtime 📝 We distribute several files that contain community contributed rules and you can always write your own. But how do you select which rules Falco will load at runtime? There are several ways, including using overrides or specifying command line options such as -D, -t and -T. However, those do not allow you to express something as simple as \u0026quot;I would like to exclude all rules except for this one\u0026quot; or \u0026quot;I would like to include a specific tag and disable some of its rules\u0026quot;. Furthermore, you couldn't specify this configuration in your falco.yaml file. To make this possible, we introduced a new configuration option, rules, that can be specified both in the configuration file or the command line. For instance, you can now write:\nrules: - disable: rule: \u0026#34;*\u0026#34; - enable: rule: Netcat Remote Code Execution in Container - enable: rule: Delete or rename shell history To finely control your rule loading without modifying the rule files themselves. Read more in controlling rules.\nField transformers and value comparison in conditions Up until now we couldn't write a condition that catches operations like \u0026quot;a process deleting its own executable\u0026quot; because you couldn't use a field value on the right hand side of the condition. Since this version we have added a syntax to do just that with the val() operator:\nevt.type = unlink and proc.exepath = val(fs.path.name) will trigger only if the process exepath is the same as the unlink argument target, meaning that the process is trying to delete its own executable!\nIn addition you can also apply simple transform operators to both sides of the comparison: toupper() and tolower() will convert casing as you'd expect and b64() can decode base64. Stay tuned for additional transformers to cover more use cases! Read more on transform operators in the documentation.\nPrometheus Metrics support 🔥 If you have been following Falco development, you probably know we are constantly improving support for metrics that tell you how the Falco engine is doing. We now have introduced Prometheus support so you can better integrate Falco with your existing performance monitoring infrastructure, and paves the way for the community to create an official Grafana dashboard that can be integrated in our charts.\nPlugin API improvements ⚙️ Plugins are getting more powerful at each version. We now have a set of experimental APIs to expose metrics and read more into the Falco internal state that our expert plugin authors have been asking about. Stay tuned for more in-depth documentation on those!\nBreaking changes and deprecations ⚠️ This version comes with breaking changes, mostly in the configuration interface\nChanged configuration options The syscall_buf_size_preset Falco configuration option has been replaced by engine.\u0026lt;driver\u0026gt;.buf_size_preset (e.g. engine.kmod.buf_size_preset) The syscall_drop_failed_exit Falco configuration option has been replaced by engine.\u0026lt;driver\u0026gt;.drop_failed_exit (e.g. engine.kmod.drop_failed_exit) The modern_bpf.cpus_for_each_syscall_buffer Falco configuration option has been replaced by engine.modern_ebpf.cpus_for_each_buffer The syscall_event_drops Falco configuration option has been replaced by the metrics config plus some automatic notification on drops. Removed command line options and equivalent configuration options The --modern_ebpf command line option has been replaced by engine.kind: modern_ebpf in falco.yaml (or, on the command line -o engine.kind=modern_ebpf). Likewise, --nodriver is now engine.kind: nodriver.\nThe environment variable FALCO_BPF_PROBE is replaced by engine.ebpf.probe configuration option. Example:\nengine: kind: ebpf ebpf: # path to the elf file to load. probe: ${HOME}/.falco/falco-bpf.o The -e option to load capture files is no longer available. In order to read a capture file use the configuration option engine.replay.capture_file. Since options can be specified on both the command line and the configuration file, an equivalent command line as falco -e \u0026lt;file.scap\u0026gt; is falco -o engine.kind=replay -o engine.replay.capture_file=\u0026lt;file.scap\u0026gt;\nThe gVisor command line options have been replaced by equivalent configuration options. -g/--gvisor-config is now engine.gvisor.config while --gvisor-root is now engine.gvisor.root. Example falco.yaml configuration file:\nengine: kind: gvisor gvisor: # A Falco-compatible configuration file can be generated with # \u0026#39;--gvisor-generate-config\u0026#39; and utilized for both runsc and Falco. config: \u0026#34;/etc/docker/runsc_falco_config.json\u0026#34; # Set gVisor root directory for storage of container state when used # in conjunction with \u0026#39;gvisor.config\u0026#39;. The \u0026#39;gvisor.root\u0026#39; to be passed # is the one usually passed to \u0026#39;runsc --root\u0026#39; flag. root: \u0026#34;/var/run/docker/runtime-runc/moby\u0026#34; Or, equivalent writing on the command line:\nfalco -o engine.kind=gvisor -o engine.gvisor.config=/etc/docker/runsc_falco_config.json -o engine.gvisor.root=/var/run/docker/runtime-runc/moby You can find more information on breaking changes in the tracking issue.\nDeprecations In Falco 0.39.0 we will remove the -D, -t, -T options, continuing our tradition of removing single-character options that nobody remembers what they do.\nTry it out Interested in trying out the new features? Use the resources below to get started.\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-no-driver (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package What’s next? Falco is more mature with each release. Following its graduation we have published the roadmap for version 1.0.0 which is guiding us in the next steps. As you can see, this version is addressing some of the roadmap points with our changes to configuration and CLI options and adding rule constructs and drivers. For the next release, you can expect more stability, streamlined container images, refinements to our rule syntax, new detections and more.\nStay connected Join us on social media and in our weekly community calls! It’s always great to have new members in the community, and we’re looking forward to hearing your feedback and ideas.\nYou can find all the most up-to-date information at https://falco.org/community/.\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.38.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-38-0/"},{"category":"blog","content":"The number of plugins available for Falco continues to grow thanks to our wonderful community. Thank you all for your help!\nYou can find the list of available plugins here.\nThe vast majority of plugins developed allow Falco to ingest logs from different sources and raise alerts when suspicious elements are identified by its rules. In order to show that any event stream can be a source if you have the right plugin, and to have something fun to show users during my talks, I developed a Falco plugin to track Bitcoin transactions.\nHow does it work? I discovered the site https://www.blockchain.com/ exposes a public flux, accessible via a websocket, by subscribing to it you can retrieve transactions carried out on the blockchain in real time. This is perfect for a Falco plugin as it allows you to test the ingestion of events via a websocket, and serve as a basis for other plugins.\nI am not going to describe the internal workings of the plugin here, nor how it was developed. If you are interested, you can look at the code here.\nAlternatively, read our documentation explaining how to create a plugin from A to Z: https://falco.org/docs/concepts/plugins/developers-guide/how-to-develop/.\nDefault rules The plugin comes with its default set of rules, we will use them as a working example. You are free to play with it for your own needs, such as monitoring suspicious movements of your wallet.\nYou can find the Falco rules file provided here.\nInstallation of the plugin We will see the 3 classic ways to install the plugin:\nvia sources with falcoctl in kubernetes via Helm Via sources The prerequisites are:\nGolang \u0026gt;= 1.19 make Falco \u0026gt;= 0.36 Git We will start by installing download the sources, build and install the plugin:\ngit clone https://github.com/Issif/bitcoin-plugin.git cd bitcoin-plugin sudo make install We will create a falco.yaml file containing:\nplugins: - name: bitcoin library_path: /usr/share/falco/plugins/libbitcoin.so init_config: \u0026#39;\u0026#39; open_params: \u0026#39;\u0026#39; load_plugins: [bitcoin] stdout_output: enabled: true The plugin comes with a default set of rules which will be sufficient for testing. All that remains is to start Falco with this command:\nsudo falco -c falco.yaml -r rules/bitcoin_rules.yaml 14:44:21.721357000: Notice The wallet bc1qfpeps3wcmzk422hvm5jeq5lelnqlzznjwyfy69 sent 96.78318104 BTC to (bc1q4hwcl377ereljtyn2t7ljdrh9umyxz5uuyl3qn,bc1qfpeps3wcmzk422hvm5jeq5lelnqlzznjwyfy69) in the transaction aab62fd0b529cd9da163508ba879d488ff64cce4c130caf6c8bd21ab1701ed46 14:44:27.020379000: Notice The wallet bc1qwk9hqnckv0ryhsnsdefcsmlpn3zx7uq3agdsw9 sent 68.68462728 BTC to (bc1qg0nkd5nckxvwlslf6lznukgat2vukrnrrcwjcv) in the transaction 734526413f6e3eefdf4adc4258e01375ccc145b9d02b7e0ab45517be0f57e7d9 14:44:29.393013000: Notice The wallet bc1qm34lsc65zpw79lxes69zkqmk6ee3ewf0j77s3h sent 14.94446421 BTC to (3F9e4JvPryCxC5A6TS4VHeT2EJSK2ivjBV,bc1qm34lsc65zpw79lxes69zkqmk6ee3ewf0j77s3h,bc1qaeq3z2edsuspt82qw7uflg0k860clxs7qjhrh0,bc1qnvhjvpa6gaglrg9lxg7w68ye8jdjcj2nk08y20,bc1q22hp7n28whk5h94z93vm05hfx2zxs8ca9gglk7,bc1qe9yxu2myqvt3kegknzj45u704dhtapwy7lxhnv,bc1qye5rp8pcqt4ej3nsz70c3lngacmew2fc4tfljd,bc1qcfqke8as8y08mkclcun9r3hlq4xl5za2vz3n2p,bc1qtqkjq4wq234netyucg247sm6nge9qu7m2fd28g,12Q4AHgzFmKWmY1Z2LEohMoxLVhvCAKsNV,3EyJiePQX4BUt8XXaAG3JmfhwB7cQ8ggp6,bc1q36ary7yaf2eeg6006h4m33drsgw4xa3pu6yvnn,13ybpB8kTgk8bCsnRrpyemNZdE2PJSHMEs,135dx8ncZzWSjhre8ecGG1yenmLwvNZPz4,3Nzr6LAJXstT8ET2CAGMH6h5vfgrh7Q94g,bc1qjhrhwpyc0z8zh6v22vhf5arzf6vcr47tgtkj5a,bc1qpxlsyrcmwuf2rk52emvfe0dvugphzzkxlyzvxv,bc1qf23j9ls2axtl6shpry40l4qat5c695x40vpfm8,bc1qsxsdunam68jkeuu7c3mplza4h74nrjhhu9w7dl,32e54ctKqWXfzKpdNKcCBBdsRoFHKoLijH,bc1qw2gafqcg2267xm2t0r4gfzu7ff392e2vl6s3zc,bc1qc0dwh27y56yajhz0k039j5p7xkwfjprhz7rfkq,3D493LGN6PchbRPtnJQo6dSUTLB8u5vN3i,3DhzjabzhAXTBU9vksNdBZFhZzMYzK7vix,18ex2LKyiLpjaSQStY1CLNbLbSToRkJAy6,bc1q3jvuvkvpukp0mnksfmpvnqq in the transaction 40c33db54610869c75b101431690e73b584b8cc77802eea76fa2d41bbb615852 14:44:29.395043000: Notice The wallet 3Hi5VHVgmYZYfAPc9aNvQoNXyEv5rYvJQN sent 50.00000000 BTC to (bc1q582qfqtlvfv038jf6k6s6xvd30we7x66katshx,bc1q6j3gxn68m5pkzhtytn3h464kgjnvce79x8nmwq,bc1qmxaaz6g07re55ekmtlmtrc5kj0kpj3lngy5y60,1CPjdsfkqiW6LB2ZNTDYczjKCzPpiJZ4Ci,1JtUKazSgYN6hCM7HPkvzL7JLVXwkL4stN,3GzfFtGVte95ZMFfQsrz3FFgFDHU8Zw6gS,bc1qcyl4sxkczex6gxldrfmfdctr2qsun4cgpufz8j,bc1q0realpv9h4zp3yhdwjeg78njqg97f9sm6ex3xrw8mkrz8g6qamsqua6tcw) in the transaction 3025c4566dc6cd6452c0c9ae6dc8cff9583df4530326b29e38e0a5e763a6c1c9 14:44:32.577196000: Notice The wallet bc1qfpeps3wcmzk422hvm5jeq5lelnqlzznjwyfy69 sent 96.43310490 BTC to (bc1qzrzhnlaru0pqmcxwm80vvvsqpdll9g6t39y686,bc1qfpeps3wcmzk422hvm5jeq5lelnqlzznjwyfy69) in the transaction 1083e02c554454db4dcff02f7418198aae5b563c4ec286b4c3ae4d30e649e8d5 14:44:32.577917000: Notice The wallet bc1qvruk6nhq5rz7whvx9cz6peqrp3nrutae59d63q sent 13.48137244 BTC to (1EtV3erwXxeKLhCvXq1BwKit7pMcB5BDvV,bc1qxgepulgdkjju7s8el6932m57svej5uzfvx7207) in the transaction 3e000a5745d7d5b6d2791bff75b9045696c2bea497363e845593ac249cc194b5 We can clearly see transactions (sending and receiving) for amounts exceeding 1 BTC appearing in real time.\nWith falcoctl The prerequisites are:\nFalco \u0026gt;= 0.36 Falcoctl \u0026gt;= 0.6 Git Falcoctl is the CLI tool that we developed to facilitate the installation of artifacts around Falco, such as rules and plugins. To find out more, here is a blog article about it.\nsudo falcoctl index add bitcoin https://raw.githubusercontent.com/Issif/bitcoin-plugin/main/index.yaml sudo falcoctl artifact install bitcoin-rules:latest Both the plugin and the rules will be downloaded thanks to the dependency:\nINFO Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; INFO Resolving dependencies ... INFO Installing the following artifacts: [ghcr.io/issif/bitcoin-plugin/ruleset/bitcoin:latest bitcoin:0.2.0] INFO Preparing to pull \u0026#34;ghcr.io/issif/bitcoin-plugin/ruleset/bitcoin:latest\u0026#34; INFO Pulling 8758e31efdff: ############################################# 100% INFO Pulling 326b3ec82baf: ############################################# 100% INFO Pulling 8aec149e9934: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/etc/falco\u0026#34; INFO Preparing to pull \u0026#34;ghcr.io/issif/bitcoin-plugin/plugin/bitcoin:0.2.0\u0026#34; INFO Pulling e7f990e1e4e6: ############################################# 100% INFO Pulling 0dfca1bb2434: ############################################# 100% INFO Pulling f269eb62cbf6: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/usr/share/falco/plugins\u0026#34; As with the installation via sources, the falco.org file should look like:\nplugins: - name: bitcoin library_path: /usr/share/falco/plugins/libbitcoin.so init_config: \u0026#39;\u0026#39; open_params: \u0026#39;\u0026#39; load_plugins: [bitcoin] stdout_output: enabled: true And Falco will be started by the command:\nsudo falco -c falco.yaml -r /etc/falco/bitcoin_rules.yaml In Kubernetes via Helm The prerequisites are:\nHelm The installation will consist of just adapting the values ​​in the values.yaml file. Everything will be automatically managed by the templates:\ntty: true kubernetes: false falco: rules_files: - /etc/falco/bitcoin_rules.yaml plugins: - name: bitcoin library_path: libbitcoin.so load_plugins: [bitcoin] falcosidekick: enabled: true webui: enabled: true driver: enabled: false collectors: enabled: false controller: kind: deployment deployment: replicas: 1 falcoctl: config: indexes: - name: bitcoin url: https://raw.githubusercontent.com/Issif/bitcoin-plugin/main/index.yaml artifact: install: refs: [\u0026#34;bitcoin:0\u0026#34;] follow: refs: [\u0026#34;bitcoin-rules:0\u0026#34;] And the classic Helm command for installation:\nhelm install falco-bitcoin -n falco falcosecurity/falco -f values.yaml --create-namespace After a few seconds, you should have the pod running:\n❯ kubectl get pods -n falco -l app.kubernetes.io/instance=falco-bitcoin NAME READY STATUS\tRESTARTS AGE falco-bitcoin-7474fbfcb5-srgsg 2/2 Running 110 (17m ago) 10d And new events in falcosidekick-ui:\nConclusion This plugin has no great purpose other than to dismantle the almost infinite possibilities that open up to Falco thanks to its plugin system. If you wish to be alerted on Telegram of a strange outgoing movement from your wallet, it is now possible with Falco!\nFalco is no longer limited to securing Cloud environments. SaaS or others can also be used in a unified way. The Falco rules syntax has proven to benefit security practitioners in an ecosystem rich with numerous potential integration points.\n","summary":"","tags":["Falco","Plugin"],"title":"Track the Bitcoin transactions with Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/track-the-bitcoin-transactions-with-falco/"},{"category":"blog","content":"I recently read an interesting blog on how hackers could use a Lambda function alongside Lex to establish persistence in an AWS account. For those unfamiliar with the term, persistence is when attackers leverage some technique to retain access to systems without being detected. A recent news article cited a study that reported that some Chinese hackers have lurked in systems for up to FIVE YEARS! Luckily for all of us, Falco can be used to detect the exact scenario detailed in the blog and immediately raise an alert.\nThe blog detailed how an attacker who has gained access to an AWS account could modify an existing Lex-based Lambda function to provide a set of AWS credentials. In short, the attacker modified the function of the Lex-based chatbot to respond whenever a secret phrase was entered with the Lambda’s AWS key ID and secret key.\nThe author notes there are several ways to establish persistence on AWS, and maybe this wasn’t the most practical, but I still found it a fun exercise. It got me thinking: How could Falco help here? My immediate thought was to use Falco’s AWS Cloudtrail plugin.\nThe plugin, as the name implies, ingests Cloudtrail events. The events can be evaluated against a set of rules to alert engineers of any suspicious activity. There are currently just over 20 different rules that can be assessed. They include scenarios like creating new users, having someone log into the root account without MFA, changing permissions on an S3 bucket, and, most relevant to our discussion here, modifying a Lambda function.\n- rule: Update Lambda Function Code desc: Detect updates to a Lambda function code. condition: ct.name=\u0026#34;UpdateFunctionCode20150331v2\u0026#34; and not ct.error exists output: The code of a Lambda function has been updated. (requesting user=%ct.user, requesting IP=%ct.srcip, AWS region=%ct.region, lambda function=%ct.request.functionname) priority: WARNING tags: - cloud - MITRE_TA0003_persistence - aws_lambda source: aws_cloudtrail Alternatively, you could create custom rules based on a whole list of AWS CloudTrail events. In the below Falco rule, we referenced the Cloudtrail event name UpdateFunctionCode20150331v2. Over 3000 event names can be used with Falco for deep incident response and forensics in the cloud.\nSo, in the scenario above, whenever the attacker modifies the function, an entry is written to the Cloudtrail logs (note that Cloudtrail is enabled by default, so no extra work is needed to get it running). Those logs would be immediately forwarded to Falco via the Cloudtrail plugin. Falco would evaluate the event against the ruleset and fire off an alert that the rule had been violated.\nThe code of a Lambda function has been updated. (requesting user=mikegcoleman, requesting IP=10.0.01, AWS region=us-west-1,lambda function=AirlinesBusinessLogic) Upon receiving the alert, an AWS engineer could review whether or not the change had been authorized and act accordingly.\nNow, it’s important to note that there are other ways that Lambda functions can be stored. For instance, the function's code can be zipped up and then stored in an S3 bucket. The rules we used above wouldn't cover this scenario. You could very likely craft a rule to ensure that a bucket’s contents have not been modified. We will save that for another blog.\nThe Falco plugins repository includes the AWS Cloudtrail plugin and plugins for Okta, GitHub, Google Cloud, and more. In fact, I recently published a walkthrough on how to use the Google Cloud plugin. Be sure to check it if you’d like to learn more about how plugins are installed and configured.\n","summary":"","tags":["security-concept"],"title":"Preventing attacker persistence with Falco on AWS","url":"https://v0-43--falcosecurity.netlify.app/blog/aws-detection/"},{"category":"blog","content":"What happened in Falco this week? First of all, you probably already heard it, Falco is now graduated!\nIf you missed this important news, go ahead and give our graduation blog post a read!\nLet's go through the major changes that happened in various repositories under the falcosecurity organization during the last week.\nLibs We are approaching the 0.15.0 tag, therefore mostly bugfixes were merged, plus a great new feature and some refactors:\nThe so-called \u0026quot;kmod configure system\u0026quot; was finally merged: https://github.com/falcosecurity/libs/pull/1452. This helps us to ensure that our kernel module builds even when some features get backported from more recent kernels (ie: when checking for kernel release version in the code is not enough). Kudos to Angelo Puglisi for shipping such a feature! Also, keep an eye for the very same thing for bpf too: https://github.com/falcosecurity/libs/pull/1729! Thanks to the kmod configure system, our kernel-testing matrix is now fully green for kmod! A big CRI API refactor finally landed: https://github.com/falcosecurity/libs/pull/1600 Proceeding with the journey around compiler sanitizers, we now have proper cmake options to enable ASAN and UBSAN: https://github.com/falcosecurity/libs/pull/1721 Fixed a crash when reading proclist from scap: https://github.com/falcosecurity/libs/pull/1726 Fixed some socketpair fds problems: https://github.com/falcosecurity/libs/pull/1733 Fixed and added some more tests: https://github.com/falcosecurity/libs/pull/1736, https://github.com/falcosecurity/libs/pull/1727 Falco Some small changes happened too, in Falco main repository:\nThe proposal about features adoption and deprecation was merged: https://github.com/falcosecurity/falco/pull/2986! Added a new configuration key falco_libs.thread_table_size to customize max thread table size in libsinsp: https://github.com/falcosecurity/falco/pull/3071 Throw an error when an invalid macro/list name is used: https://github.com/falcosecurity/falco/pull/3116 Fixed up directory iteration options while iterating over rule folder: https://github.com/falcosecurity/falco/pull/3127 Join relevant discussions Our new discussion section: https://github.com/falcosecurity/falco/discussions Breaking changes in Falco 0.38.0: https://github.com/falcosecurity/falco/issues/2840 Breaking changes in Falco 0.39.0: https://github.com/falcosecurity/falco/issues/3045 Let's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Open a discussion in our discussion section Thanks to all the amazing contributors!\nCheers 🎊\nFederico\n","summary":"","tags":["Falco"],"title":"Falco Weekly 10 - 2024","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-w-10-2024-weekly-recap/"},{"category":"blog","content":"Today, the Falco project hit a big milestone: becoming a CNCF Graduated Project! Falco's graduation indicates the project's maturity and dependability, but most importantly, it is the culmination of a fantastic amount of work.\nThe journey for Falco started in 2016 when the first commit was made. Today, Falco has become synonymous with \u0026quot;runtime security\u0026quot; due to its comprehensive approach to securing the highly complex and dynamic environments of the modern cloud era.\n“Falco approaches the security challenges associated with managing cloud native environments holistically,” says Loris Degioanni, the project’s founder. ”Runtime security is more than eBPF-based data collection, it requires enrichment, orchestrator integration, correlation of different data sources, and a rich, well-maintained policy library. All of the things that Falco provides to its users.”\nThis holistic, runtime-centric approach to security is what makes Falco unique. It enables any organization to secure their infrastructure — from scrappy startups to Fortune 500s. Since joining the CNCF, some of the largest enterprises in the world, including Amazon, Apple, IBM, and Red Hat, have contributed to Falco. The project also has a strong, rapidly growing community of adopters and has been downloaded over 100 million times!\nTo the thousands of people who have helped Falco fly over the past years, thank you — sincerely. Thank you to the Falco maintainers. Thank you to our CNCF Technical Oversight Committee sponsors, Emily Fox and Justin Cormack. Thank you to anyone who has ever raised an issue, submitted a pull request on GitHub, or just took part in our community.\nThank you, also, to the thousands of organizations who have entrusted Falco with the security of your runtime environments.\nFor us, Falco’s Graduation represents a calling to continue to improve the project in a way that serves its users. We believe that runtime protection is vital to security, and that Falco is well positioned to power that security as we move deeper into the cloud era.\nIn the future, Falco will have even stronger detections, richer signals, lower noise, and better performance. Its breadth of coverage will increase with more data sources, including cloud logs and key developer touchpoints like GitHub. Future versions of Falco will be even easier to deploy and manage in production.\nOur mission is to make Falco a powerful companion that brings you peace of mind, knowing your cloud native apps are well looked after. We hope you will continue to be part of this journey with us.\nWords from our community Graduation means a lot to the members of our community. We asked them to share their thoughts and feelings with us on this occasion. Here is what they had to say:\n\u0026quot;Since joining the Falco project in 2020, I've been inspired by our community's growth and commitment to open source values. Falco has unequivocally established itself as the quintessential tool for cloud native runtime security, leveraging key technologies like eBPF – notably, becoming one of the largest open source eBPF codebases. As we reach the CNCF graduation milestone, I'm immensely proud of our collective achievements and want to thank every contributor who has played a role in this journey.\u0026quot; - Leonardo Grasso, Falco core maintainer\n\u0026quot;Linux kernel security monitoring is undeniably mission-critical, in great demand, yet daunting to master. Working within the kernel can be intimidating due to its potential impact on application performance and the sheer volume of events on modern servers. Since joining in 2022, The Falco Project has adapted to meet new demands while staying true to its mission, and this journey continues to accelerate. Observing Falco's effectiveness and value in real-world production settings is truly beautiful.\u0026quot; - Melissa Kilby, Falco core maintainer\n\u0026quot;Back when I joined the Falco community, the project was a teenager that needed some love; here we are, it took a little while but it is now an adult! And I loved every little bit of its growth! What do I love more? The fact that we still have a lot of space for improvements, everywhere. This is good for users, the wider community and for us, developers and maintainers of the projects, to keep the fun with it.\u0026quot; - Federico Di Pierro, Falco core maintainer\n\u0026quot;It has been a long journey since my first try of Falco. It was its very first release, Kubernetes was a small thing and the containers started to become the game changer we know now. I'm very proud having been a modest piece of this achievement, developing tools for Falco made me a better DevOps, a better Go developer, an international speaker and it made me meet amazing users and contributors. It's a good thing to see it’s rising as a standard for the runtime security in the industry. I hope it will help even more SREs to peacefully sleep at night.\u0026quot; - Thomas Labarussias, Falco core maintainer\n\u0026quot;The project's rapid growth is evident with each new milestone, and I take great pride in being a member of this team, of this family. There's boundless potential for the project's expansion, and I see this milestone as the first step toward an even brighter future.\u0026quot; - Andrea Terzolo, Falco core maintainer\n\u0026quot;I have been following Falco for many years now and I am impressed by how far the project has come. I am personally proud and happy that I could be a part of the stellar team that drives Falco; thanks to maintainer's and contributor's efforts we were able to achieve incredible goals and it is great to see the project being recognized alongside the most successful in the CNCF. Thanks to everyone who has been with us in this journey and everyone who will join us in the future.\u0026quot; - Luca Guerra, Falco core maintainer\n\u0026quot;It's hard to believe that more than two years have already passed since I joined the amazing open source community of Falco. I can't express my deep gratitude for all our supporters and for the Falco family. This project gave me the privilege of connecting with incredibly skilled humans, and of witnessing the growth of a beautiful piece of technology that's now a fundamental security asset for countless organizations in the industry. Looking back, I feel immensely proud of all the collective efforts that led the project to this huge milestone, and I can't wait to see what the future holds from this point forward.\u0026quot; - Jason Dellaluce, Falco core maintainer\n\u0026quot;Today, I am immensely proud as Falco graduates within the CNCF. This achievement is a testament to the dedication of our maintainers and the broader community of adopters and contributors. Together, we’ve propelled Falco to become the industry’s de-facto standard for runtime threat detection in the cloud. I am deeply grateful for the collaborative efforts that have brought us to this moment. The tireless work, expertise, and passion shared by our team and community have elevated Falco’s capabilities, ensuring its effectiveness in safeguarding organizations against evolving security threats. As we enter this new chapter within the CNCF, I am confident in our collective ability to continue innovating and strengthening Falco’s position as a vital tool in the fight for cloud security.\u0026quot; - Michele Zuccala, Falco core maintainer\n\u0026quot;Since I joined, contributing to the ecosystem with passion and excitement to know more about and to contribute to this project, I've found a welcoming, vibrant, and healthy community as well as a strong maintainership. With time, the community grew and grew, and independence and diversity increased during these years. Nowadays, runtime security in the cloud native world is becoming more and more fundamental in our architectures, and Falco has become one of the de-facto standards for increasing observability in our Linux kernel-based cloud native systems. The project has evolved a lot during the last couple of years. I remember the design proposal for plugins back then! Thanks to the incredible work of the maintainers and the contributors, and now I can't explain how much this big step and acknowledgment from the CNCF matter! Congratulations to the Falco family!\u0026quot; - Massimiliano Giovagnoli, Falco core maintainer\n","summary":"","tags":["Falco"],"title":"Falco Graduates within the CNCF!","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-graduation/"},{"category":"blog","content":"What happened in Falco this week? Let's go through the major changes that happened in various repositories under the falcosecurity organization.\nLibs Multiple fixes and some cleanups happened in the libs repo:\nnewfstatat syscall is now configured with UF_ALWAYS_DROP: https://github.com/falcosecurity/libs/pull/1683 Fixed null destination address in sendto and sendmsg in modern bpf: https://github.com/falcosecurity/libs/pull/1687 Added a CT_UNKNOWN container type zero value and properly initialize uninitialized value: https://github.com/falcosecurity/libs/pull/1688 Fix in chisels: don't fail if a chisel directory does not exist: https://github.com/falcosecurity/libs/pull/1689 Cleaned up more memory reads/writes in filterchecks to avoid UBs: https://github.com/falcosecurity/libs/pull/1690 Properly initialize m_exe... fields in threadinfo: https://github.com/falcosecurity/libs/pull/1691 Fixed a small source of memleak in scap platform: https://github.com/falcosecurity/libs/pull/1692 Properly enforce the static CRT on Windows by default: https://github.com/falcosecurity/libs/pull/1695 Falco Falco has seens quite a bit of C++ improvements, thanks to Samuel Gaist! Keep up the great job!\nC++ cleanups: https://github.com/falcosecurity/falco/pull/3069, https://github.com/falcosecurity/falco/pull/3074, https://github.com/falcosecurity/falco/pull/3083, https://github.com/falcosecurity/falco/pull/3085 Consolidated Faclo engine and rule loader tests: https://github.com/falcosecurity/falco/pull/3066 Added http-headers option to Falco driver-loader images: https://github.com/falcosecurity/falco/pull/3075 Cleaned up an unused builder Dockerfile: https://github.com/falcosecurity/falco/pull/3088 Fixed some compiler warnings: https://github.com/falcosecurity/falco/pull/3089 Cleaned up falco_engine deps and include paths: https://github.com/falcosecurity/falco/pull/3090 Falcoctl Falcoctl has seen a small yet important fix:\nCorrectly report artifact type: https://github.com/falcosecurity/falcoctl/pull/442 Kernel-testing Even if the effort was part of last week, and since we skipped last \u0026quot;Weekly Recap\u0026quot;, it is important to mention that the kernel-testing framework recently got a big update:\nAll images build is now tested in PR CI when they are modified Images are now build and published on ghcr.io/falcosecurity/kernel-testing repo They are published under main tag and under latest|$tag for releases The image name is built as: $distro-{kernel,image}:$kernelrelease-$arch-$imagetag, eg: amazonlinux2-kernel:5.10-x86_64-v0.3.2 Ubuntu-6.3 images were bumped to 6.5 kernel A new arch-6.7 image was added to the test matrix A composite action was added and is now used by libs CI As always, you can find detailed kernel-testing outputs against our drivers under https://falcosecurity.github.io/libs/matrix/.\nCharts Thanks to Aldo's continuous effort, we now have much better documentation all around the repo:\nUpdated docs for Falco exporter: https://github.com/falcosecurity/charts/pull/623, Process all charts for changes in values.yaml: https://github.com/falcosecurity/charts/pull/624 Updated contributing section: https://github.com/falcosecurity/charts/pull/625 Fixed typos, formatting and dead links in Falco chart docs: https://github.com/falcosecurity/charts/pull/627 Fixed dead links for Falco exporter: https://github.com/falcosecurity/charts/pull/628 Fixed link tags in readme: https://github.com/falcosecurity/charts/pull/629 Join relevant discussions Our new discussion section: https://github.com/falcosecurity/falco/discussions Breaking changes in Falco 0.38.0: https://github.com/falcosecurity/falco/issues/2840 Breaking changes in Falco 0.39.0: https://github.com/falcosecurity/falco/issues/3045 Let's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Open a discussion in our discussion section Thanks to all the amazing contributors!\nCheers 🎊\nFederico\n","summary":"","tags":["Falco"],"title":"Falco Weekly 7 - 2024","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-w-7-2024-weekly-recap/"},{"category":"blog","content":"Today we announce the release of Falco 0.37.1 🦅!\nFixes Falco's 0.37.1 release is a small patch aimed at addressing a few minor bugs. It includes the following:\nAdded --http-insecure flag to driver loader images Added new env variable FALCOCTL_DRIVER_HTTP_HEADERS understood by driver loader images to pass a comma separated list of http headers for driver download, eg: FALCOCTL_DRIVER_HTTP_HEADERS='x-emc-namespace: default,Proxy-Authenticate: Basic' Falcoctl was bumped to v0.7.2, fixing an issue building Flatcar drivers and a bug withing the kernel release fixup method to build drivers download URLs Fixed a nasty bug that caused Falco to crash when a priority higher than debug was set in the config: https://github.com/falcosecurity/falco/pull/3060 Libs were updated to 0.14.3 Last, but not least, as recommended by the CNCF, we now link libelf dynamically instead of statically, so that the library remains separable from Falco at runtime.\nThis has multiple outcomes:\nFalco static (musl) build is disabled for now; we are experimenting with some solutions and we will hopefully be able to bring it back up soon Users of docker images won't notice anything since they already shipped libelf library Users of deb and rpm packages won't notice anything since libelf was already a nested dependency Users of the tar.gz package will need to manually install libelf where not present Thanks to everyone in the community for helping us in spotting these annoying bugs 🐛! You make Falco successful 🦅!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nTry it! 🏎️ As usual, in case you just want to try out the stable Falco 0.37.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Prefer to use a container image? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader Let's meet 🤝 We meet every Wednesday in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nFederico\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.37.1","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-37-1/"},{"category":"blog","content":" Falco Talon Repository: https://github.com/Falco-Talon/falco-talon Falco Talon Documentation: https://docs.falco-talon.org/ Falco Talon is currently under active development and remains in the alpha stage; therefore, breaking changes may occur at any time, and the documentation may not always be up to date.\nSetting up robust network security in Kubernetes is a challenge that demands both precision and adaptability. NetworkPolicy offers the potential for highly specific network configurations, enabling or blocking traffic based on a comprehensive set of criteria. However, the dynamic nature of network topologies and the complexities of managing policy implementations present ongoing challenges. The need for constant policy updates, especially in response to changing threat landscapes, introduces risks such as the potential for misconfiguration and the unintended dropping of packets.\nThe Challenge of IP-Based Network Policies Building network policies around IP addresses is notoriously challenging. For instance, threat feeds, which list known malicious IP addresses, are constantly changing. An IP address associated with a malicious entity one week might be reassigned and deemed safe the next. This fluidity necessitates an agile approach to network policy management, integrating solutions like NetworkSets to dynamically update policies based on the latest intelligence. However, the sheer volume of threat intelligence feeds – from Tor IP lists to cryptomining blocklists – complicates this integration, making it a daunting task to maintain accurate network controls.\nHere, Falco Talon emerges as a transformative solution. By leveraging Falco's detection capabilities, such as identifying Outbound Connections to C2 Servers, Falco Talon can instantly update Kubernetes network policies to block all egress traffic except allowed CIDR ranges. This is facilitated through the kubernetes:networkpolicy Talon action, demonstrating a seamless integration of dynamic threat detection with network policy enforcement.\n- action: Disable outbound connections actionner: kubernetes:networkpolicy parameters: allow: - \u0026#34;192.168.1.0/24\u0026#34; - \u0026#34;172.17.0.0/16\u0026#34; - \u0026#34;10.0.0.0/32\u0026#34; rule: Suspicious outbound connection match: rules: - Outbound Connections to C2 Servers actions: action: Disable outbound connections While this would certainly block the egress network connections, it’s not really convenient for some organizations as it’s a scorched-earth approach to blocking traffic but still relies on an IP-based allowlist on each Talon rule - rather than blocking the actual suspicious IP address specified in the Falco rule. Instead, we will propose the use of labels as a response action in Talon to better isolate network traffic at runtime.\nShifting from IPs to Labels for Network Security While IP-based blocking is effective in response to specific threats detected by Falco, it's not the most scalable solution for ongoing network policy management in production environments. An alternative approach focuses on using labels to create quarantine-style network policies. This method involves configuring a network policy that applies a default-deny stance on all ingress and egress traffic for pods matching certain labels, effectively isolating potentially compromised workloads. This can easily be achieved with the below one-liner:\nkubectl label pod \u0026lt;pod-name\u0026gt; -n \u0026lt;namespace-name\u0026gt; quarantine=true This is certainly a cleaner approach than the previous enforced network policy implementation, but the challenge here is the manual process of labeling those suspected workloads, which can be cumbersome and slow in response to emerging threats. How many minutes will it take our security team to enforce this label action, and what happens if this happens over the weekend?\nFalco Talon addresses this gap with its kubernetes:labelize response action. Upon detecting a threat, such as the Detect outbound connections to common miner pool ports, Talon can automatically apply a quarantine:true label to the affected pod, triggering the enforcement of the quarantine network policy in real-time. This capability not only enhances the speed and efficiency of response actions but also underscores the power of integrating dynamic threat detection with network policy enforcement.\n- action: Quarantine Pod in Network Policy actionner: kubernetes:labelize parameters: labels: quarantine: true rule: Suspicious outbound connection match: rules: - Detect outbound connections to common miner pool ports actions: action: Quarantine Pod in Network Policy While Talon can apply the label, you still need a component that will enforce the quarantine. Most CNI's can do this, but for the purpose of this blog I'll add an example with Calico:\napiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: quarantine spec: selector: quarantine == \u0026#34;true\u0026#34; ingress: - action: Deny source: {} destination: {} egress: - action: Deny source: {} destination: {} types: - Ingress - Egress Conclusion The integration of Falco Talon into Kubernetes network security strategies represents a significant advancement in the field. By automating the enforcement of network policies based on real-time threat detection, Falco Talon simplifies the complexities associated with managing network security in a constantly evolving landscape. Whether responding to immediate threats through IP-based policies or proactively isolating workloads with label-based quarantine policies, Falco Talon provides a flexible, powerful tool for enhancing the security and resilience of Kubernetes environments. As organizations navigate the challenges of cloud-native security, solutions like Falco Talon offer a beacon of adaptability and effectiveness, ensuring that network security keeps pace with the dynamic nature of containerized deployments.\n","summary":"","tags":["security-concept"],"title":"Automate Kubernetes Network Security with Falco Talon","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-network-security/"},{"category":"blog","content":"Dear Falco Community, today we are happy to announce the release of Falco 0.37.0!\nThis release brings an improved installation experience, a new way to modify Falco rules, and some great UX improvements. There are, as to be expected, a handful of breaking changes. But, rest assured, we've done all we can to help you with any changes you might need to make.\nDuring this release cycle, we merged more than 100 PRs on Falco and more than 160 PRs for libs and drivers, version 0.14.2 and version 7.0.0 respectively. Thank you to our maintainers and contributors, as this would not happen without your support and dedication!\nTo learn all about these changes, read on!\nWhat’s new? TL;DR Key features:\nA new way to enrich syscalls with Kubernetes metadata, replacing the old Kubernetes collector. New capabilities in falcoctl to download and build our kernel drivers, replacing the old falco-driver-loader script. Support for 32-bit syscall emulation on x86_64 in all kernel drivers (modern_ebpf, ebpf, kernel module). A new override key to easily modify rules, lists, and macros. Key UX improvements:\nIntroduction of a new engine key in falco.yaml to replace all other methods for opening engines such as FALCO_BPF_PROBE, --modern-bpf, -g, and -e. Expansion of environment variables in falco.yaml even when they are part of a string. This release also comes with breaking changes, we'd suggest to read them before upgrading. If you use helm, make sure to read the Helm chart breaking changes page as well.\nMajor features and improvements The 0.37.0 release contains a number of feature and UX improvements, here are list of some of the key new capabilities.\nA new way to enrich syscalls with K8s metadata Falco 0.37.0 introduces a new method to enrich syscalls with Kubernetes metadata to help address scalability and other issues with the old collector. Falco always had Kubernetes support, but sometimes we need new approaches to keep up with the bigger and bigger scale that we see in production clusters today. You can find more technical details here.\nWhile the collector was previously integrated into Falco, this feature uses a new architecture which leverages a plugin (k8smeta) and a remote collector (k8s-metacollector).\nThe plugin gathers details about Kubernetes resources from the remote collector. It stores this information and provides access to Falco upon request. The plugin specifically acquires data for the node where the associated Falco instance is deployed, resulting in node-level granularity. In contrast, the collector runs at the cluster level.\nWithin a given cluster there may be multiple k8smeta plugins (one per node), but only one collector exists per cluster.\nMore technical details about the architecture and design choices are here.\nIt’s important to note that both new components are considered experimental, which means although they are functional and tested, they are currently in active development. They may undergo changes in behavior as necessary without prioritizing backward compatibility.\nFields supported by the new k8smeta plugin This section provides details on:\nKubernetes fields that are supported out-of-the-box by Falco through container runtime enrichment. Fields the new k8smeta plugin supports Fields have been deprecated. The following fields are automatically populated with data from the container runtime, making them compatible with Falco without needing the old k8s collector or the new k8smeta plugin. These fields will continue to function as before, and no changes have been made:\nk8s.pod.name k8s.pod.id/k8s.pod.uid k8s.pod.sandbox_id k8s.pod.full_sandbox_id k8s.pod.label k8s.pod.labels k8s.pod.ip k8s.pod.cni.json k8s.ns.name All other fields with the k8s.* prefix previously supported by the old collector (e.g., k8s.deployment.name) are now deprecated and will return \u0026lt;NA\u0026gt; if used in rules.\nThese fields are now provided by the new plugin under the k8smeta.* prefix. A complete list of these fields can be found here\nThe new fields introduced by the k8smeta plugin are additive. They do not replace the fields provided by the container runtime. This means you can use both k8s.pod.name and k8smeta.pod.name simultaneously. While they may return the same value, the data is collected from different sources (container runtime for k8s fields, the Kubernetes API server for k8smeta). As a result, their availability and reliability may differ during the lifecycle of an application. While it may seem redundant, this approach should offer flexibility to users.\nTo wrap up:\nIf k8s.pod.* and k8s.ns.name fields meet your needs, you can use Falco without plugins. The default container runtime information in Falco should be enough. If k8s.pod.* and k8s.ns.name fields are insufficient, you should evaluate the new k8smeta plugin. The old k8s.* fields (excluding k8s.pod.* and k8s.ns.name) are now deprecated, and if used in Falco rules, they return \u0026lt;NA\u0026gt; If you’d like to read more about this new feature check out the documentation for the k8smeta pluginand the k8s-metacollector, while if you want to deploy this solution with our helm chart check out the dedicated section.\nNew Falcoctl capabilities Since falcoctl 0.7.0, users have been able to quickly download and compile Falco drivers using the falcoctl driver command. Starting with Falco 0.37.0 the falcoctl driver command will be used by the Falco installation process in place of the old falco-driver-loader script.\nFor example, to install the kernel module:.\nSpecify which driver we want to use falcoctl driver config --type kmod Install the driver falcoctl driver install By default, the falcoctl driver install command tries to download a prebuilt driver from the official Falco download s3 bucket. If a driver is found, then it is inserted into ${HOME}/.falco/. Otherwise, the script tries to compile the driver locally.\nYou can find more details on installing each driver type in our docs.\nFinally, while the falcoctl driver command replaces the old falco-driver-loader script it’s important to note that, even though there is no change in terms of usage, the Docker images falco-driver-loader and falco-driver-loader-legacy no longer utilize the old falco-driver-loader script; instead, they now use falcoctl.\n32-bit syscall emulation The support for 32-bit syscalls has consistently been a highly requested feature for a long time. Until now, this support was only available in the kernel module, but starting from Falco 0.37.0, we have finally extended this support to the ebpf and modern_ebpf drivers. This feature is crucial as it addresses a security gap that has existed for some time.\nIt’s important to note that this feature is specifically for 32-bits syscalls emulated on the x86_64 architecture. Falco does not support pure 32-bit architectures.\nFollow these steps to try out this new feature:\nCreate a C program ia32.c #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; #include \u0026lt;sys/syscall.h\u0026gt; #include \u0026lt;sys/types.h\u0026gt; int main() { syscall(__NR_close, -1); return 0; } Compile it gcc ia32.c -o ia32 -m32\nStart Falco with the following rule evt.type = close and proc.name contains ia32\nExecute the binary\n./ia32\nYou should see the rule triggered\nNew override key Falco 0.37.0 replaces the append: true key-value pair with a new override section. The override section allows you to either replace or append keys to a rule, macro, or list value . It’s important to note that you cannot append and replace the same key; you must choose one or the other. Choosing both will result in an error.\nThe keys that can be modified vary according to the rules component being overridden. See the override documentation for the full list of keys that can be modified.\nThe override section can either be in a custom rules file or can be in the same file as the component being overridden. In either case, the override section needs to be specified after the rule that is being modified. When the override is in the same file, the override section needs to be below the original rule, list, or macro definition. If the override is in another file, that file needs to be loaded after the original rules file.\nA quick example from the documentation illustrates how this new feature works.\nIn this example, the original rule is in falco_rules.yaml and the override is specified in falco_rules.local.yaml.\n/etc/falco/falco_rules.yaml\n- rule: program_accesses_file desc: track whenever a set of programs opens a file condition: proc.name in (cat, ls) and evt.type=open output: a tracked program opened a file (user=%user.name command=%proc.cmdline file=%fd.name) priority: INFO /etc/falco/falco_rules.local.yaml\n- rule: program_accesses_file condition: and not user.name=root output: A file (user=%user.name command=%proc.cmdline file=%fd.name) was opened by a monitored program override: condition: append output: replace The modified program_accesses_filerule would trigger when ls or cat use open on a file, unless they were run by root.\nThe new output message would be A file (user=%user.name command=%proc.cmdline file=%fd.name) was opened by a monitored program\nA final note, the old append: true method of modifying values has been deprecated and will be removed in Falco 1.0.0.\nAdditional UX improvements Introduce a new unique engine key in falco.yaml to replace all the other methods of opening engines (FALCO_BPF_PROBE, --modern-bpf, -g, -e). See the deprecated features section for more info.\nFalco now expands environment variables in falco.yaml even when they are part of a string. It is now possible to use syntax similar to this:\nebpf: probe: ${HOME}/.falco/falco-bpf.o Our gVisor integration has also been improved by adding support for more events, including write, socketpair, timerfd_create and an updated configuration generator. In addition, we added support for any gVisor container ID format, making Falco more robust and compatible with gVisor sandboxed containers beyond Docker and Kubernetes. Breaking changes This is a list of breaking changes introduced in Falco 0.37.0\nThe Rate-limiter mechanism was removed as it is no longer used.\n--userspace CLI option was removed as it’s no longer used.\nThe falco-driver-loader script is removed and embedded into falcoctl\nThe Helm chart 4.0.0 contains several modifications to work with the new k8s metadata collector. Please read its breaking change file for more information.\nThe new falcoctl driver implementation will drop:\n--source-only BPF_USE_LOCAL_KERNEL_SOURCES DRIVER_CURL_OPTIONS The FALCO_BPF_PROBE environment variable won't be used by the new falcoctl driver loader as it is already deprecated and scheduled to be removed in the next major version. Various environment variables have been replaced as part of the new falcoctl driver feature:\nDRIVERS_REPO has been replaced by FALCOCTL_DRIVER_NAME or the --name command line argument. DRIVERS_NAME has been replaced by FALCOCTL_DRIVER_REPOS or the --repo command line argument. DRIVER_KERNEL_RELEASE has been replaced by --kernelrelease command line argument. DRIVER_KERNEL_VERSION has been replaced by --kernelversion command line argument. DRIVER_INSECURE_DOWNLOAD has been replaced by --http-insecure command line argument. Remove -K/-k options from Falco in favor of the new k8s plugin\nDropped plugins shipped with Falco since plugins will now be managed by falcoctl. If you want to use a plugin like k8saudit be sure to install it at init time with falcoctl.\nA new feature in Falco 0.37.0 allows environment variables to be expanded even if they are part of a string. This new functionality introduces a minor breaking change.\nPreviously, environment variables used in YAML that were empty or defined as “” would be expanded to the default value. This was inconsistent with how YAML was handled in other cases, where we only returned the default values if the node was not defined.\nWith Falco 0.37.0 we will return the default value for nodes that cannot be parsed to the chosen type. The program_output command will be environment-expanded at init time instead of letting popen; thus, the shell expands it.\nThis is technically a breaking change, even if no behavioral change is expected.\nNote that you can avoid environment var expansion by using ${{FOO}} instead of ${FOO}. It will resolve to ${FOO} and won't be resolved to the environment var value.\nYou can find more information on breaking changes in the tracking issue.\nDeprecated features This is a list of features that will be removed in Falco 0.38.0\nModern probe Docker builder is no longer used. syscall_buf_size_preset Falco config in favor of engine.kmod/ebpf/modern_ebpf.buf_size_preset. syscall_drop_failed_exit Falco config in favor of engine.kmod/ebpf/modern_ebpf.drop_failed_exit. modern_bpf.cpus_for_each_syscall_bufferFalco config in favor of engine.modern_ebpf.cpus_for_each_buffer. FALCO_BPF_PROBE environment variable in favor of engine.ebpf.probe. -e command line flag in favor of engine.replay.capture_file. g,gvisor-config command line flag in favor of engine.gvisor.config. gvisor-root command line flag in favor of engine.gvisor.root. modern-bpf command line flag in favor of engine.kind=modern_ebpf. nodriver command line flag in favor of engine.kind=nodriver. syscall_event_drops falco config will be replaced by the metrics config plus some automatic notification on drops. Be sure to check the tracker issue for more information.\nTry it out Interested in trying out the new features? Use the resources below to get started.\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-no-driver (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package What’s next? The community is active on many fronts, and we plan on delivering more great features and stability fixes during the next release cycle!\nSome of the things we are currently working on include:\nImplement further improvements to our rule framework and rule syntax. Add new features and enhancements to falcoctl to make it even more powerful. Enhance the quantity, quality, and presentation of metrics in Falco. And much much more\nStay connected Join us on social media and in our weekly community calls! It’s always great to have new members in the community, and we’re looking forward to hearing your feedback and ideas.\nYou can find all the most up-to-date information at https://falco.org/community/.\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.37.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-37-0/"},{"category":"blog","content":"What happened in Falco this week? Let's go through the major changes that happened in various repositories under the falcosecurity organization.\nLibs Libs will need a 0.14.2 tag for the Falco 0.37.0 release, with the revert of https://github.com/falcosecurity/libs/pull/1533 PR.\nDuring our release process, we found out that the new std::filesystem based implementaton was up to 8x time slower than the old ones; that's because it supports much more cases and does many more checks.\nTherefore, in https://github.com/falcosecurity/libs/pull/1645, we revert to the old sorcery implementation, plus some minor improvements and added tests.\nMoreover, many more changes landed in libs, that won't be part of the upcoming Falco 0.37.0 release:\nModernized C++ struct/enum/union declarations: https://github.com/falcosecurity/libs/pull/1588 Added support for newfstatat syscall: https://github.com/falcosecurity/libs/pull/1628 Fixed a potential deadlock for kmod: https://github.com/falcosecurity/libs/pull/1629 Big effort by our hero, Jason, to cleanup some stale macros: https://github.com/falcosecurity/libs/pull/1633,https://github.com/falcosecurity/libs/pull/1634,https://github.com/falcosecurity/libs/pull/1635,https://github.com/falcosecurity/libs/pull/1637,https://github.com/falcosecurity/libs/pull/1638 A small fix for old ebpf driver to support some GKE envs: https://github.com/falcosecurity/libs/pull/1642 Solved a data race and segfault in logger: https://github.com/falcosecurity/libs/pull/1643 Allow to selectively disable bpf and kmod engines from cmake: https://github.com/falcosecurity/libs/pull/1644 Falco Falco tag 0.37.0-rc2 is out! Try it!\nMoreover:\nsyscall_event_drops was soft-deprecated to get ready for Falco 0.38.0 upcoming cleanups: https://github.com/falcosecurity/falco/pull/3015 Avoid storing escaped strings in engine: https://github.com/falcosecurity/falco/pull/3028 Bumped falcoctl to v0.7.1 and rules to 3.0.0: https://github.com/falcosecurity/falco/pull/3030,https://github.com/falcosecurity/falco/pull/3034 Fixed nlohmann_json library include paths when using system one: https://github.com/falcosecurity/falco/pull/3032 Fixes to new libsinsp state metrics handling: https://github.com/falcosecurity/falco/pull/3033 We are in the testing phase so any feedback would be appreciated! Moreover, we crafted a dedicated helm chart to test the new k8smeta plugin and the k8s-metacollector, you can read more about it here. Please note these 2 new components will be officially released with Falco 0.37.0 as EXPERIMENTAL features.\nAs a final reminder, please take a look at our polls if you have some spare seconds.\nFalcoctl Falcoctl 0.7.1 is out! Try it! and contains a small fix for the driver-loader on COS.\nMoreover, we added dependabot configs, that then bumped lots of deps to their latest compatible versions: https://github.com/falcosecurity/falcoctl/pull/385.\nJoin relevant discussions Our new discussion section: https://github.com/falcosecurity/falco/discussions Breaking changes in Falco 0.37.0: https://github.com/falcosecurity/falco/issues/2763 Breaking changes in Falco 0.38.0: https://github.com/falcosecurity/falco/issues/2840 Let's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Open a discussion in our discussion section Thanks to all the amazing contributors!\nCheers 🎊\nAldo, Andrea, Federico\n","summary":"","tags":["Falco"],"title":"Falco Weekly 4 - 2024","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-w-4-2024-weekly-recap/"},{"category":"blog","content":"What happened in Falco this week? Let's go through the major changes that happened in various repositories under the falcosecurity organization.\nLibs Libs tag 0.14.1 is out! Try it!\nIt fixes the following things:\nfix(gvisor): gVisor engine crashes with non-hex container IDs: https://github.com/falcosecurity/libs/issues/1602 fix(gvisor): handle arbitrary sandbox IDs: https://github.com/falcosecurity/libs/pull/1612 fix(libsinsp): modify switch case: https://github.com/falcosecurity/libs/pull/1620 fix(libsinsp): Add new cgroup layout for podman: https://github.com/falcosecurity/libs/pull/1613 fix(libsinsp): consistent thread info filtering while dumping: https://github.com/falcosecurity/libs/pull/1606 fix(libsinsp): do not suppress zero ptids: https://github.com/falcosecurity/libs/pull/1598 fix(libsinsp): fix resolved PT_FSPATH and PT_FSRELPATH evt params: https://github.com/falcosecurity/libs/pull/1597 You can find a detailed summary on the release page.\nFalco Falco tag 0.37.0-rc1 is out! Try it!\nSome final cleanup before the final tag:\ncleanup(falco.yaml): rename none in nodriver: https://github.com/falcosecurity/falco/pull/3012 update(config): graduate outputs_queue to stable: https://github.com/falcosecurity/falco/pull/3016 We are in the testing phase so any feedback would be appreciated! Moreover, we crafted a dedicated helm chart to test the new k8smeta plugin and the k8s-metacollector, you can read more about it here. Please note these 2 new components will be officially released with Falco 0.37.0 as EXPERIMENTAL features.\nAs a final reminder, please take a look at our polls if you have some spare seconds.\nFalcoctl Falcoctl 0.7.0 is out! Try it!\nThese are some of the most relevant changes:\nupdate(output): complete rework of the output system: https://github.com/falcosecurity/falcoctl/pull/335 update(cmd): remove redundant configuration for error handling: https://github.com/falcosecurity/falcoctl/pull/337 new(cmd): add artifact config command: https://github.com/falcosecurity/falcoctl/pull/340 feat(artifact/config): fetch config layer for a specific platform: https://github.com/falcosecurity/falcoctl/pull/349 new(artifact/manifest): add manifest command: https://github.com/falcosecurity/falcoctl/pull/351 new: driver command: https://github.com/falcosecurity/falcoctl/pull/343 new(pkg/driver): fixed some kernel version related issues: https://github.com/falcosecurity/falcoctl/pull/364 cleanup(cmd,internal,pkg): move driver config options to be common to all driver commands: https://github.com/falcosecurity/falcoctl/pull/365 fix(pkg/driver): do not call FixupKernel when building drivers: https://github.com/falcosecurity/falcoctl/pull/373 new: introduce asset artifact type: https://github.com/falcosecurity/falcoctl/pull/309 You can find a detailed summary on the release page.\nJoin relevant discussions Our new discussion section: https://github.com/falcosecurity/falco/discussions Breaking changes in Falco 0.37.0: https://github.com/falcosecurity/falco/issues/2763 Breaking changes in Falco 0.38.0: https://github.com/falcosecurity/falco/issues/2840 Let's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Open a discussion in our discussion section Thanks to all the amazing contributors!\nCheers 🎊\nAldo, Andrea, Federico\n","summary":"","tags":["Falco"],"title":"Falco Weekly 3 - 2024","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-w-3-2024-weekly-recap/"},{"category":"blog","content":"What happened in Falco this week? Let's go through the major changes that happened in various repositories under the falcosecurity organization.\nLibs The anticipated 0.14.0 libs tag (and its driver counterpart) are going to be tagged soon, by the end of next week.\nA xmas present for you all! :christmas_tree:\nMostly fixes were merged during this week:\nPopulate labels field for pod sandbox containers: https://github.com/falcosecurity/libs/pull/1564 Improved libscap modern bpf tests and CI checks: https://github.com/falcosecurity/libs/pull/1568 Avoid a double free when an exception is thrown during sinsp initialization: https://github.com/falcosecurity/libs/pull/1569 Made our pkg-config files paths-relative: https://github.com/falcosecurity/libs/pull/1570 Fixed some paths handling in fs.path: https://github.com/falcosecurity/libs/pull/1571 Do not include NULL terminator in enter event strings: https://github.com/falcosecurity/libs/pull/1574 Started a dedicated container engines test suite: https://github.com/falcosecurity/libs/pull/1544 Rewritten scary concatenate_paths function leveraging modern c++17 std::filesystem: https://github.com/falcosecurity/libs/pull/1533 Use a smart pointer for m_resolver in sinsp_dns_manager to avoid leaks: https://github.com/falcosecurity/libs/pull/1558 Also, thanks to actuated.dev for offering us arm64 github action runners, CI has been fully ported to github actions, except for a single CircleCI job! https://github.com/falcosecurity/libs/pull/1555\nRumors have it coming next:\nDrivers build fix against linux 6.7-rc4+: https://github.com/falcosecurity/libs/pull/1566 Add k8s.pod.uid, k8s.pod.sandbox_id and mark k8s.pod.id as legacy: https://github.com/falcosecurity/libs/pull/1575 Falco Falco has seen some big new features this week!\nEnv variables expansion was extended to all scalar values in Falco configuration file! https://github.com/falcosecurity/falco/pull/2918, https://github.com/falcosecurity/falco/pull/2972 Leveraging the above, engine.ebpf.probe path now defaults to ${HOME}/.falco/falco-bpf.o: https://github.com/falcosecurity/falco/pull/2971 CI has been ported to use actuated.dev github action arm64 runners! https://github.com/falcosecurity/falco/pull/2945, https://github.com/falcosecurity/falco/pull/2967 Monitor more types of events for Falco hot reload feature: https://github.com/falcosecurity/falco/pull/2965 libs and driver were bumped to latest master: https://github.com/falcosecurity/falco/pull/2970 Finally, the new falcoctl based driver-loader was finally merged in Falco: https://github.com/falcosecurity/falco/pull/2905.\nIf you can, please make sure to give it a spin and let us know any feedback, it is very valuable for us!\nTo try it out:\ndocker pull falcosecurity/falco-driver-loader:master docker run --rm -i -t \\ --privileged \\ -v /root/.falco:/root/.falco \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules \\ -v /usr:/host/usr:ro \\ -v /etc:/host/etc:ro \\ falcosecurity/falco-driver-loader:master Falcoctl Some fixes on top of the new driver-loader happened:\nCleanup eBPF probe symlink in Cleanup method: https://github.com/falcosecurity/falcoctl/pull/371 Do not call FixupKernel when building drivers: https://github.com/falcosecurity/falcoctl/pull/373 Moreover, we finally merged the new asset artifact type PR! https://github.com/falcosecurity/falcoctl/pull/309\nFalcoctl is quite ready for v0.7.0 release; we only need more driver-loader testing!\nDriverkit Driverkit has seen a small bug fix release this week: https://github.com/falcosecurity/driverkit/releases/tag/v0.16.2.\nIt contains a fix to docker go package multiplexed output support: https://github.com/falcosecurity/driverkit/pull/310.\nMoreover, we merged a PR that opens up the possibility for Driverkit to directly use cmake to configure and then build our drivers: https://github.com/falcosecurity/driverkit/pull/309.\nWhat's next?\nThe cmake PR is opened and works super good; build times are as good as before, so no penalty! https://github.com/falcosecurity/driverkit/pull/302.\nMoreover, we are going to make use of actuated.dev arm64 runners in driverkit too, porting its CI to github actions: https://github.com/falcosecurity/driverkit/pull/311.\nJoin relevant discussions! Breaking changes in Falco 0.37.0: https://github.com/falcosecurity/falco/issues/2763 Breaking changes in Falco 0.38.0: https://github.com/falcosecurity/falco/issues/2840 Let's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nAldo, Andrea, Federico\n","summary":"","tags":["Falco"],"title":"Falco Weekly 50 - 2023","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-w-50-2023-weekly-recap/"},{"category":"blog","content":"In cloud-native environments, where applications scale up and down much faster than traditional monolithic application architectures, the ability to proactively identify and respond to threats in real time is paramount. As more organizations embrace cloud-native architectures for application delivery, more robust security measures need to be introduced. In this blog post, we delve into the dynamic realm of Kubernetes threat detection by exploring how open source Falco can seamlessly detect Atomic Red Team tests in real time within Kubernetes environments.\nAtomic Red Team is a powerful framework designed to simulate real-world attacks, providing organizations with a controlled environment to validate the effectiveness of their security measures. We take this a step further by deploying Atomic Red to Kubernetes with a single command, creating a realistic testing ground for evaluating the responsiveness of Falco.\nOur journey begins with the effortless deployment of Atomic Red to Kubernetes, showcasing the simplicity and efficiency of orchestrating security testing within containerized environments. Once deployed, we invoke specific Atomic Red Team tests, simulating a range of threat scenarios. The true test lies in Falco's ability to detect these threats in line with the MITRE ATT\u0026amp;CK framework, a globally-recognized matrix mapping adversary techniques to defensive tactics.\nThis exploration is not just about identifying threats; it's a collaborative effort to enhance Falco's coverage. Should we identify any gaps in detection, we dive deeper, revising the executed techniques and crafting custom rules. This iterative process aims to extend our MITRE ATT\u0026amp;CK coverage, aligning Falco with the industry's best practices for threat detection and mitigation.\nDeploying Atomic Red Team To avoid any potential service disruption in production environments, we recommend installing Atomic Red in a test lab environment, or at least a staging environment of Kubernetes. We have a step-by-step video for installing Atomic Red on Youtube\nBefore we start the deployment, remember to create the atomic-red network namespace.\nkubectl create ns atomic-red A single pod will be deployed with privileged set to true. Atomic Red requires admin-level securityContext to perform certain actions that require elevated permissions.\nkubectl apply -f - \u0026lt;\u0026lt;EOF apiVersion: apps/v1 kind: Deployment metadata: name: atomicred namespace: atomic-red labels: app: atomicred spec: replicas: 1 selector: matchLabels: app: atomicred template: metadata: labels: app: atomicred spec: containers: - name: atomicred image: issif/atomic-red:latest imagePullPolicy: \u0026#34;IfNotPresent\u0026#34; command: [\u0026#34;sleep\u0026#34;, \u0026#34;3560d\u0026#34;] securityContext: privileged: true nodeSelector: kubernetes.io/os: linux EOF Note: This creates a pod called 'atomicred' in the 'atomic-red' network namespace. You can check on the state of the installation with the below command:\nkubectl get pods -n atomic-red If you ever want to remove the Atomic Red project from your Kubernetes cluster, simply run:\nkubectl delete deployment atomicred -n atomic-red Familiarize Yourself with Atomic Red Tests Once deployed, you will need to shell into the Atomic Red pod to perform the following test scenarios. This might seem a little confusing, but Atomic Red was developed with PowerShell in mind, so the below instructions ask the user to shell into a container, and once they are in the running pod, they must run Powershell to import and invoke the various Atomic Test Scenarios.\nOnce you are familiar with this logic, you’ll find Atomic Red is a truly simple security simulation tool.\nkubectl exec -it -n atomic-red deploy/atomicred -- bash As mentioned, you need to run Powershell once you are in the Atomic Red pod:\npwsh Now, you can finally load the Atomic Red Team module:\nImport-Module \u0026#34;~/AtomicRedTeam/invoke-atomicredteam/Invoke-AtomicRedTeam.psd1\u0026#34; -Force Check the details of the TTPs:\nInvoke-AtomicTest T1070.004 -ShowDetails Check the prerequisites to ensure the test conditions are right:\nInvoke-AtomicTest T1070.004 -GetPreReqs You can see in the below screenshot, there are no prerequisites required to perform these tests. As a result, we can invoke the bulk file deletion test scenario.\nRemove the feature flags to execute the test simulation.\nInvoke-AtomicTest T1070.004 This test will attempt to delete individual files or individual directories. When we have Falco installed, this Atomic test should trigger the 'Warning bulk data removed from disk' rule by default. Next, we discuss Falco’s installation.\nCongrats! Now that we know how Atomic Red works, let’s install Falco and run it side-by-side against Atomic Red to prove it detects these tests in real time. We will need to open two terminal windows to see the real-time response detections.\nInstalling \u0026amp; Testing Falco For this lab guide, we can install Falco via Helm on a fixed version prior to the segregation of rules into different rules feeds, such as 'incubating', 'sandbox' and 'stable'. The reason we are doing this is to ensure all Falco rules are accessible in our lab scenario. To use the latest version of Falco, simply remove the '--version' feature flag from the Helm install script.\nhelm install falco falcosecurity/falco --namespace falco \\ --create-namespace \\ --set tty=true \\ --version 3.3.0 Just like the Atomic Red deployment, we need to monitor the progress of the Falco installation. The pods will change state a few times during the installation, but should eventually all be in a 'RUNNING' status after about a minute or so.\nPlease use the below command to check on the status change of Falco pods:\nkubectl get pods -n falco -w Once Falco is installed, we can track the events as they are generated using the following command in the second terminal window.\nkubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco Jump back into the first terminal window and re-run the bulk file deletion Atomic Test - 'T1070.004':\nInvoke-AtomicTest T1070.004 You’re going to identify certain noise in the detection rules. For example, all Atomic Tests are run under the 'Root' user, therefore, we will always get a detection for scripts running under root. To ignore this noise, let’s instead just check for the specific Falco rule we are looking to detect:\nkubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep \u0026#39;Bulk data has been removed from disk\u0026#39; Hurrah! We see the exact detection matching the context of the Atomic Red test scenario. Let’s move on to the next Atomic Test to invoke. There are a bunch of test scenarios for Linux that you can test out today.\nCheck out the list on the official Atomic Red Team Github project.\nT1556.003 Modify Authentication Process In this scenario, Atomic Red generates three Pluggable Authentication Modules (PAM): two malicious PAM rules for Linux and FreeBSD, as well as a malicious PAM module for Linux. These programs can be used to open and read sensitive file content, and we can agree that they are non-trusted programs. Again, we have an out-of-the-box rule for these activities:\nkubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep \u0026#39;Sensitive file opened for reading by non-trusted program\u0026#39; Now, it's time to simulate our threat:\nInvoke-AtomicTest T1556.003 T1036.005 Masquerading: Match Legitimate Name or Location This test scenario executes a process from a directory masquerading as the current parent directory.\nkubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep \u0026#39;Executing binary not part of base\u0026#39; Now, it's time to simulate our threat.\nInvoke-AtomicTest T1036.005 You can see that in the left terminal window, there is an echo message in the terminal saying '”Hello from the Atomic Red Team.”' Any string output in the command line can also be detected in Falco’s outputs.\nT1070.002 Indicator Removal on Host Adversaries may clear system logs to hide evidence of an intrusion. macOS and Linux both keep track of system or user-initiated actions via system logs. The majority of native system logging is stored under the '/var/log/' directory.\nkubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep \u0026#39;Log files were tampered\u0026#39; Now, it's time to simulate our threat:\nInvoke-AtomicTest T1070.002 T1070.003 Clear Command History In addition to clearing system logs, an adversary may clear the command history of a compromised account to conceal the actions undertaken during an intrusion. Various command interpreters keep track of the commands users type in their terminals so that users can retrace what they've done.\nkubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep \u0026#39;Shell history had been deleted or renamed\u0026#39; Now, it's time to simulate our threat:\nInvoke-AtomicTest T1070.003 You can see from the below screenshot that four different operations were performed. Therefore, four unique Falco detections were triggered on those individual attempts to clear the command line history.\nT1014 Loadable Kernel Module Based Rootkit Adversaries may use Rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components. Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information.\nRootkits may reside at the user or kernel level in the operating system or lower, to include a hypervisor, Master Boot Record, or System Firmware. As such, it’s critical that Falco detects Rootkits in real time.\nkubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep \u0026#39;Linux Kernel Module injection from container detected\u0026#39; Now, it's time to simulate our threat:\nInvoke-AtomicTest T1014 Falco is detecting the Linux kernel module injection attempt, whether it was a successful execution or not.\nT1037.004 [CUSTOM RULE] Boot Initialization - RC Scripts Adversaries may establish persistence by modifying RC scripts that are executed during a Unix-like system’s startup. These files allow system administrators to map and start custom services at startup for different run levels. RC scripts require root privileges to modify.\nCommand to simulate the 'T1037.004' test:\nInvoke-AtomicTest T1037.004 You’ll notice that this is the first test where we don’t get a useful Falco detection related to the threat. As a result, we need to create a 'custom-rules.yaml' file with the custom Falco rule for detecting boot initialization scripts.\ncat \u0026gt; custom-rules.yaml \u0026lt;\u0026lt;EOF customRules: custom_rules.yaml: |- - rule: Base64-encoded Python Script Execution desc: \u0026gt; This rule detects base64-encoded Python scripts on command line arguments. condition: \u0026gt; spawned_process and ( ((proc.cmdline contains \u0026#34;python -c\u0026#34; or proc.cmdline contains \u0026#34;python3 -c\u0026#34; or proc.cmdline contains \u0026#34;python2 -c\u0026#34;) and (proc.cmdline contains \u0026#34;echo\u0026#34; or proc.cmdline icontains \u0026#34;base64\u0026#34;)) or ((proc.cmdline contains \u0026#34;import\u0026#34; and proc.cmdline contains \u0026#34;base64\u0026#34; and proc.cmdline contains \u0026#34;decode\u0026#34;))) output: \u0026gt; Potentially malicious Python script encoded on command line (proc.cmdline=%proc.cmdline user.name=%user.name proc.name=%proc.name proc.pname=%proc.pname evt.type=%evt.type gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt.res=%evt.res container.id=%container.id container.name=%container.name file=%fd.name) priority: warning tags: - T1037.004 - MITRE_Defense_Evasion source: syscall EOF Adversaries can establish persistence by adding a malicious binary path or shell commands to 'rc.local', 'rc.common', and other RC scripts specific to the Unix-like distribution. Upon reboot, the system executes the script's contents as root, resulting in persistence.\nLet’s try upgrading Falco to reflect the 'custom-rules.yaml' file:\nhelm upgrade falco falcosecurity/falco \\ -n falco \\ --set tty=true \\ --version 3.3.0 \\ --reuse-values \\ -f custom-rules.yaml Granted, there’s no obvious formatting issues when creating the 'custom-rules.yaml' manifest, you should be able to successfully upgrade Falco and the pods should be in a 'RUNNING' state. If there was an issue with the custom rules file, the Falco pod state will likely change to 'CrashLoopBackOff'.\nLet’s see if we detect the Atomic test after upgrading Falco with the newly-created custom rule. Remember to have Falco running in a second terminal window with the following command:\nkubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep \u0026#39;Potentially malicious Python script\u0026#39; We can simulate the technique ID 'T1037.004' one last time:\nInvoke-AtomicTest T1037.004 Hurrah! We detected the boot initialization scripts with the above command. To recap, adversaries looking to abuse those RC scripts are especially effective for lightweight Unix-like distributions using the root user as default, such as IoT or embedded systems. If you are wondering why the Falco rule was specifically looking at Base64-encoded Python scripts, well, we need to look back at the details associated with the Atomic test simulation.\nInvoke-AtomicTest T1037.004 -ShowDetails We can see from the command that it is using the 'python3' command to run Python scripts. However, the script itself is executed as a base64-encoded string to evade some traditional detection tools.\nConclusion In conclusion, this article serves as a comprehensive guide aimed at enhancing knowledge in cloud-native threat simulation and detection. Its primary audience includes security practitioners, DevOps teams, and anyone involved in securing Kubernetes environments. The focal point is the utilization of Atomic Red for deploying test simulations aligned with the MITRE ATT\u0026amp;CK framework and leveraging Falco to detect these threats in real time.\nThe article not only illustrates how Atomic Red can be instrumental in improving the rules shipped with Falco, but also emphasizes its role in identifying potential gaps in coverage. By doing so, it offers a valuable resource for customers seeking alternative methods to validate the effectiveness of their Falco rules and, consequently, fortify the security posture of their Kubernetes deployments.\nThe notion of creating a realistic testing ground for evaluating the responsiveness of Falco is particularly beneficial for DevOps teams. This facet addresses the need for hands-on experience in threat simulation, adversarial approaches, and understanding the intricacies of the MITRE ATT\u0026amp;CK framework. In providing this practical testing environment, the article empowers DevOps teams to proactively enhance their security measures, ensuring robust coverage and responsiveness in the dynamic landscape of Kubernetes threat detection.\n","summary":"","tags":["security-concept"],"title":"Install and Test Atomic Red in Kubernetes","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-atomic-red/"},{"category":"blog","content":"What happened in Falco this week? Let's go through the major changes that happened in various repositories under the falcosecurity organization.\nLibs The anticipated 0.14.0 libs tag (and its driver counterpart) are still a bit late, unfortunately.\nAnyway, spring cleaning went on once again this week!\ncleaned up dup3 flags param: https://github.com/falcosecurity/libs/pull/1469 cleaned up other params inconsistencies in the drivers: https://github.com/falcosecurity/libs/pull/1512 dropped b64 dep: https://github.com/falcosecurity/libs/pull/1518 dropped tinydir dep: https://github.com/falcosecurity/libs/pull/1516 removed some warning suppressions: https://github.com/falcosecurity/libs/pull/1519 cleaned up big unused function sinsp_evt::get_param_as_json: https://github.com/falcosecurity/libs/pull/1523 The big safer parameter handling PR was merged, making libs much more robust! Moreover, ppc64le support was extended to kmod and legacy ebpf probe, and we added CI jobs to test the build of drivers on it! Thanks to Afsan Hossain for his big contribution!\nFinally, some more fixes:\nbuild on s390x was fixed: https://github.com/falcosecurity/libs/pull/1522 some recently introduced regressions were fixed: https://github.com/falcosecurity/libs/pull/1524 fixed a memleak in sinsp_dns_manager: https://github.com/falcosecurity/libs/pull/1526 Rumors have it coming next week:\nMore fixes: https://github.com/falcosecurity/libs/pull/1530, https://github.com/falcosecurity/libs/pull/1528 Falco We bumped libs and driver to latest master: https://github.com/falcosecurity/falco/pull/2929.\nMoreover, Falco will now print system info during startup: https://github.com/falcosecurity/falco/pull/2927.\nFalco does now expose a new config option to enable libsinsp state metrics: https://github.com/falcosecurity/falco/pull/2883 Finally, the new driver selection mechanism PR was merged!\nFalcoctl Some fixes on top of the new driver-loader happened:\nfixed up naming for the new Falco driver selection in config: https://github.com/falcosecurity/falcoctl/pull/357 small fix for host-root driver-loader configuration: https://github.com/falcosecurity/falcoctl/pull/358 do not fail when /sys/kernel/debug fails to be mounted: https://github.com/falcosecurity/falcoctl/pull/361 Join relevant discussions! Breaking change in Falco 0.37.0: https://github.com/falcosecurity/falco/issues/2763 Breaking change in Falco 0.38.0: https://github.com/falcosecurity/falco/issues/2840 Falco metrics exposed to final users: https://github.com/falcosecurity/falco/issues/2928 Create a more coherent stats model for libs: https://github.com/falcosecurity/libs/issues/1463 Allow loading tracepoints other than the ones needed by Falco: https://github.com/falcosecurity/libs/issues/1376 Let's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nAldo, Federico\n","summary":"","tags":["Falco"],"title":"Falco Weekly 48 - 2023","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-w-48-2023-weekly-recap/"},{"category":"blog","content":"Identity Threat Detection \u0026amp; Response (ITDR) in the cloud is of paramount importance to limit access to sensitive data and maintain the integrity of cloud infrastructure. Leading cloud providers like AWS, Microsoft Azure, and Google Cloud have implemented robust Identity and Access Management (IAM) controls, as well as Multi-Factor Authentication (MFA) options, to ensure that users have the standardized access control limitations.\nHowever, as the saying goes, \u0026quot;Trust, but verify.\u0026quot; Even with these layers of security, there's a growing concern about what happens when a rogue employee or an external adversary manages to compromise an identity provider. Recent months have witnessed a surge in attacks targeting popular identity providers like Okta, underscoring the critical need for timely and effective detection capabilities. In fact, (Crowdstrike’s 2023 Threat Hunting) report had classified 62% of all interactive cyber intrusions as having involved some form of compromised identities.\nWithout proper detection, incidents such as the attacks on organizations like Caesars and MGM might go unnoticed until it's too late. Fortunately, open source Falco offers a Dedicated plugin for the Okta identity platform, empowering security teams to respond swiftly and with the context required to take real action against potential threats.\nIn this blog post, we will delve into how Falco fulfills the requirements for ITDR capabilities. We'll illustrate the significance of Falco's adaptable rule logic and provide readers with a real-world example of crafting custom rules derived directly from Okta audit logs.\nUnderstanding the rule logic The Falco Okta plugin comes with a set of valuable default rules for Okta logs, which are designed to assist you in enhancing the security of your Okta platform.\nA typical illustration of the importance of these rules lies in the process of initiating a password reset within the Okta platform. In practice, an insider threat might reset a password, opt not to inform the end-user about the reset, and potentially carry out an account takeover in this context. Whenever a specific action is executed through the Okta user interface, there is a straightforward method to access the associated activity logs on the web user interface\nNonetheless, this default perspective is not particularly suitable for our Falco rule since it's focused on a specific user making changes to another specific user account. The system log focus is on algorithmically-generated actor IDs linked to both the user initiating the password reset and the user whose account password has been reset.\nWhile this event information may serve a purpose if you only wish to trigger detection events between these specific accounts, in practical scenarios, a more comprehensive view encompassing all users is typically required.\nFor a more efficient approach, it's advisable to select the User updated password in Okta event behavior shown at the bottom of the screenshot above. This action will automatically narrow down the search view to display event information exclusively related to password updates in Okta. With this method, we can effectively set up alerts for all password update activities.\nUtilizing Falco, we can extract the precise event type value from the system log and incorporate it into a Falco rule.\nFortunately, this task has already been handled for us in the Okta plugin ruleset. It's worth noting that the value found in the system logs aligns with our specified Falco conditions, ensuring that we attain equivalent visibility within Falco as we do in the Okta UI. However, it's important to be aware that in extensive production environments, this rule can generate a significant amount of noise. If needed, you have the option to filter this activity specifically for password resets targeting the 'Admin' privileged group, as they are frequently the primary targets of cyberattacks.\n- rule: User password reset by OKTA admin desc: Detect a password reset on a user done by OKTA Admin Account condition: okta.evt.type = \u0026#34;user.account.reset_password\u0026#34; output: \u0026#34;A user password has been reset by an OKTA Admin account (user=%okta.actor.name, ip=%okta.client.ip, target user=%okta.target.user.name)\u0026#34; priority: NOTICE source: okta tags: [okta] Here is the output displayed in our Falcosidekick UI, presenting the context of the actor's name and the corresponding IP address responsible for the change. It could be advantageous to explore the possibility of incorporating additional Output fields to enhance incident response capabilities when addressing identity threats.\nBuilding a custom Falco rule The next example extends beyond the scope of the default Falco rules. For instance, if an identity integration or application were to be disassociated from the user Nigel Douglas, it might be an attempt to compromise security measures within established workflows or systems - a good example of Impair Defenses technique in the MITRE ATT\u0026amp;CK matrix.\nConsequently, we will replicate this specific action and create a custom Falco rule to identify such behavior. As shown in the screenshot below, the admin user is seen removing the application assignment from the user Nigel.\nAfter the application has been unassigned, we receive the updated event type data in Okta, much like our previous workflow. The Okta query that provides the results of the application removal is as follows:\neventType eq \u0026#34;application.user_membership.remove\u0026#34; With this understanding, we can navigate to the falco_rules.local.yaml file in our Falco installation, which is often used to define a custom ruleset. Based on the construction of the previous Falco rule and the string identified in the screenshot above application.user_membership.remove, we will update the condition to check for this type. In your case, the Falco rule should be structured as follows:\n- rule: Remove app membership desc: Detect membership removal in OKTA condition: okta.evt.type = \u0026#34;application.user_membership.remove\u0026#34; output: \u0026#34;A user has removed the following app in OKTA (user=%okta.actor.name, ip=%okta.client.ip, target user=%okta.target.user.name)\u0026#34; priority: CRITICAL source: okta tags: [custom_rule, mitre_defense_evasion, T1562, impair_defenses] To ensure the custom rule is applied, you might need to restart Falco (depending on the version). If you have deployed Falco and Falcosidekick via a Docker compose file, this can be achieved by simply executing a stop command to halt the containers, followed by the up -d command, which restarts the Docker containers with the same configurations specified in the docker-compose.yaml file.\nWhile Docker is not the only deployment option for Falco, it is undeniably a very convenient option for these types of test environments. The source of the docker-compose.yaml can be accessed here .\ndocker compose -f docker-compose.yaml stop docker compose -f docker-compose.yaml up -d In order to assist with incident response initiatives, you will now notice the custom tags linked to MITRE ATT\u0026amp;CK tactics and techniques in your alert output. This enhanced alert output facilitates incident responders in recognizing the specific issues related to this behavior, enabling them to potentially detect insider threats at the earliest stage. These custom tags are then integrated into the Falco rule for further context.\nWhy Falco instead of a traditional logging solution? While it's possible to forward all your Okta logs to a centralized Security Incident \u0026amp; Event Management (SIEM) system, certain limitations become apparent. One prominent concern pertains to storage, as a substantial number of events must be retained in a centralized backend database, requiring aggregation and indexing to produce security alerts. This can impose a significant operational burden on organizations since they are effectively storing a multitude of events, a significant portion of which may be extraneous, potentially resulting in substantial costs associated with ingestion charges.\nSimilarly, once the events are in the system, it becomes crucial to have a solid grasp of crafting effective detection rules. Instead of managing intricate scripts and queries to minimize false positives, Falco streamlines the process by offering a unified rules language applicable across host endpoints, cloud services, CI/CD services, and Okta logs. This approach enables swift rule development and immediate testing within your environment without incurring ingestion charges. Furthermore, Falco addresses the issue of centralized storage bloat through its intelligent streaming engine, which processes event context and makes decisions on whether to trigger alerts based on specific event metadata, rather than indiscriminately ingesting all associated events.\nFinally, the entire process of manually executing Okta search queries in the web UI, or managing intricate detection scripts, can be time-consuming and often results in coverage gaps. Falco offers a solution by delivering a nearly real-time detection engine that enables the use of macros and lists for complex querying. For instance, consider the task of verifying whether the user Nigel Douglas is logging in from their usual IP address. Instead of navigating through complex Okta queries, you can simply use the actor ID, cross-referencing it with the typical IP they use for sign-ins, and also taking into account the context of their access, such as interactions with the Admin Dashboard or other elements within the Okta user interface.\nThis is how Okta queries can be structured:\neventType eq \u0026#34;user.session.access_admin_app\u0026#34; and client.ip_address eq \u0026#34;78.xx.xxx.249\u0026#34; and target.id eq \u0026#34;00u9xcz5aphuQ8ZQq5d7\u0026#34; and outcome.result eq \u0026#34;SUCCESS\u0026#34; Yet, if our aim is to identify successful login attempts from questionable geographic regions or IP addresses, we must integrate lists and diligently keep them up-to-date. This is where the following Falco rule proves its worth:\n- rule: Suspicious Login for Nigel Douglas desc: Detect suspicious login attempts from known suspicious IPs condition: okta.evt.type = \u0026#34;user.session.access_admin_app\u0026#34; and okta.client.ip in (suspicious_ips) and okta.target.user.id= \u0026#34;00u9xcz5aphuQ8ZQq5d7\u0026#34; output: Suspicious IP Inbound Request (okta.actor.name=%okta.actor.name, okta.client.ip=%okta.client.ip, okta.target.user.id=%okta.target.user.id, okta.target.user.name=%okta.target.user.name, okta.app=%okta.app, okta.evt.type=%okta.evt.type) priority: CRITICAL tags: [custom_rule, mitre_initial_access, T1078, valid_accounts] source: okta Next, we create a list that compiles all potentially identified malicious actors who may attempt an account takeover on a legitimate account, which should typically be accessed from a consistent IP address. This list logic can be applied to geolocations, such as countries, instead of specific IPs. In both scenarios, the list is named suspicious_ips and is referred to in the Falco rule conditions as follows:\n- list: suspicious_ips items: [\u0026#34;103.236.201.88\u0026#34;, \u0026#34;104.244.74.23\u0026#34;, \u0026#34;107.189.13.251\u0026#34;, \u0026#34;118.163.74.160\u0026#34;, \u0026#34;125.212.241.131\u0026#34;, \u0026#34;176.58.100.98\u0026#34;, \u0026#34;176.58.121.177\u0026#34;, \u0026#34;179.43.128.16\u0026#34;, \u0026#34;179.48.251.188\u0026#34;, \u0026#34;180.150.226.99\u0026#34;, \u0026#34;181.214.39.73\u0026#34;, \u0026#34;185.10.16.41\u0026#34;, \u0026#34;185.100.85.132\u0026#34;, \u0026#34;185.100.85.22\u0026#34;, \u0026#34;185.100.85.23\u0026#34;, \u0026#34;185.100.85.25\u0026#34;, \u0026#34;185.191.204.254\u0026#34;, \u0026#34;185.195.71.10\u0026#34;, \u0026#34;185.195.71.12\u0026#34;, \u0026#34;185.195.71.4\u0026#34;, \u0026#34;185.195.71.5\u0026#34;, \u0026#34;185.195.71.6\u0026#34;, \u0026#34;185.195.71.7\u0026#34;, \u0026#34;185.195.71.8\u0026#34;, \u0026#34;185.220.101.3\u0026#34;, \u0026#34;185.82.219.109\u0026#34;, \u0026#34;195.80.151.30\u0026#34;, \u0026#34;198.58.107.53\u0026#34;, \u0026#34;198.98.60.90\u0026#34;, \u0026#34;199.249.230.100\u0026#34;, \u0026#34;199.249.230.107\u0026#34;, \u0026#34;199.249.230.109\u0026#34;, \u0026#34;199.249.230.113\u0026#34;, \u0026#34;199.249.230.117\u0026#34;, \u0026#34;199.249.230.119\u0026#34;, \u0026#34;199.249.230.121\u0026#34;, \u0026#34;199.249.230.140\u0026#34;, \u0026#34;199.249.230.157\u0026#34;, \u0026#34;199.249.230.165\u0026#34;, \u0026#34;199.249.230.180\u0026#34;, \u0026#34;199.249.230.70\u0026#34;, \u0026#34;199.249.230.71\u0026#34;, \u0026#34;199.249.230.78\u0026#34;, \u0026#34;199.249.230.85\u0026#34;, \u0026#34;199.249.230.88\u0026#34;, \u0026#34;199.249.230.89\u0026#34;, \u0026#34;200.122.181.2\u0026#34;, \u0026#34;204.194.29.4\u0026#34;, \u0026#34;205.185.119.35\u0026#34;] Finally, we get the detection that there was a login from a suspicious IP address. We changed the Priority to CRITICAL to reflect the severity of a suspicious login from a malicious IP.\nThis is just one instance demonstrating the capabilities of Falco. I encourage you, as the reader, to explore various innovative approaches for crafting customized detection rules that align with your unique zero-trust architecture strategy. Should you have recommendations on enhancing default detection rules in Falco for Okta identity logs, please don't hesitate to reach out to us directly. We are always open to discussions: https://falco.org/community/ .\nStrengthening Identity Security with Falco: Next Steps In a landscape where identity threats are on the rise, extending to identity providers themselves, as exemplified by the recent Okta security breach, organizations are compelled to enhance their identity management and cybersecurity preparedness. After reading this article, you should hopefully have a deeper appreciation for Falco and its user identity security approach.\nEvaluating your existing runtime security can be a valuable starting point, particularly if you identify gaps in Okta log coverage, making Falco a worthwhile consideration. And this very plugin logic can be extended to AWS and Google Cloud Platform via their own response logging services - AWS Cloudtrail and GCP Audit Logs.\nFor those interested in delving deeper into recent identity-related attacks, you can explore the article on DarkReading, where we delve into how ITDR solutions can be employed to detect Okta Cross-Tenant Impersonation Attacks .\nIf you're interested in installing Falco on a test machine and integrating the Okta plugin, you can find helpful deployment script at Luca Guerra’s Github repo: https://github.com/LucaGuerra/falcosidekick-ui-compose/blob/main/falco.yaml .\nTo configure the Okta plugin, you can easily uncomment the section below and input your Okta details as needed. If you're uncertain about how to obtain your Okta API token, you can refer to this resource for guidance: https://developer.okta.com/docs/guides/create-an-api-token/main\n- name: okta library_path: libokta.so init_config: organization: xxxxx # as in https://xxxxx.okta.com api_token: yyyyy # your Okta API token open_params: \u0026#39;\u0026#39; ","summary":"","tags":["architecture","event-source"],"title":"Using Falco to Create Custom Identity Detections","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-okta-identity/"},{"category":"blog","content":"Another week, another load of improvements everywhere in the falcosecurity!\nWhat happened in Falco this week? Let's go through the major changes that happened in various repositories under the falcosecurity organization.\nLibs The anticipated 0.14.0 libs tag (and its driver counterpart) are a bit late, unfortunately.\nAnyway, spring cleaning went on this week!\nremoved stopwatch implementation, now unused: https://github.com/falcosecurity/libs/pull/1493 removed unused sinsp_test.cpp file: https://github.com/falcosecurity/libs/pull/1499 removed jq dep: https://github.com/falcosecurity/libs/pull/1500 Moreover, some fixes on the recently introduced async event queue class happened: https://github.com/falcosecurity/libs/pull/1490, https://github.com/falcosecurity/libs/pull/1504. Finally, some fixes around the stats code: https://github.com/falcosecurity/libs/pull/1505, https://github.com/falcosecurity/libs/pull/1506.\nRumors have it coming next week:\nNew big cleanup: deprecation of tracers: https://github.com/falcosecurity/libs/pull/1503 ppc64le support for bpf and kmod + CI build jobs: https://github.com/falcosecurity/libs/pull/1497 remove old metaevents implementation: https://github.com/falcosecurity/libs/pull/1495 Small fix on top of ia32 work: https://github.com/falcosecurity/libs/pull/1501 Second part of an effort by Luca Guerra to clean up libsinsp from potential undefined behavior: https://github.com/falcosecurity/libs/pull/1502.\nThis is so important that deserved to be left alone :)\nFalco We have a new official adopter! Welcome to Thought Machine: https://github.com/falcosecurity/falco/pull/2919 Small cleanup to avoid Falco configuratiom to be inited twice: https://github.com/falcosecurity/falco/pull/2917\nFalcoctl The new driver command was merged! https://github.com/falcosecurity/falcoctl/pull/343 We are now in the process of adding tests and eventually fixing spotted bugs :) Also, the new asset artifact type PR is being reviewed: https://github.com/falcosecurity/falcoctl/pull/309.\nOthers Driverkit v0.16.0 was just released, and contains some fixes, a new local build processor and preliminary SLES support.\nLet's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nFederico\n","summary":"","tags":["Falco"],"title":"Falco Weekly 47 - 2023","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-w-47-2023-weekly-recap/"},{"category":"blog","content":"One of the big advantages of running your workloads on a managed Kubernetes service like Google Kubernetes Engine (GKE) is that Google ensures your clusters are being deployed and managed following industry best practices.\nWhile GKE clusters are incredibly secure and reliable, there is always room for improvement.\nIn this blog, we’re going to describe how you can enhance GKE’s already great security by adding runtime threat detection with Falco.\nWhat is Falco? Falco is a Cloud Native Computing Foundation project that provides runtime threat detection. Out of the box, Falco examines syscalls to alert you to any suspicious activity. And, since containers share the same kernel as their host, Falco can monitor not only activity on the host but also activity on all of the containers running on that host. Moreover, Falco pulls data from both Kubernetes and the container runtime to add additional context to its alerts.\nWith Falco running on your GKE clusters you can be notified of a wide variety of events, such as:\nDid someone start a container with high privileges? Has someone shelled into a running container? Has an executable been added to the container after it was deployed? These are just a few examples. Falco has over 80 rules that can be used to make you aware of not only external threats but also when clusters aren’t being operated in accordance with industry best practices.\nGKE Installation considerations There are two different ways to install Falco on GKE. The first is using the prepackaged click-to-run offering in the Google Cloud Marketplace. The second is using Falco’s helm chart. The click-to-run offering is probably the simplest way to get up and running with Falco on GKE, but the drawback is that the version offered often lags behind the latest release.\nIt’s also important to note that as of this writing, you cannot run Falco on GKE clusters running in Autopilot mode. This is primarily because Falco uses an init container running with privileged access to install its driver, and Autopilot does not allow the execution of privileged containers.\nSomething else to be aware of is that Falco on GKE needs to use one of Falco’s eBPF drivers. Falco uses a driver to capture syscall events, and this driver is offered as a loadable kernel module or as an eBPF probe. There are actually two eBPF probes with Falco. One is called ‘eBPF’ (or classic eBPF) and the other is referred to as ‘modern eBPF’ - you can learn more about them in the Falco docs.\nOn the Google Cloud side, GKE uses Container-Optimized OS (COS) as the default operating system for its worker node pools. COS is a security-enhanced operating system that limits access to certain parts of the underlying OS. Because of this security constraint, Falco cannot insert its kernel module to process system calls. However, COS does support eBPF, so that’s the option we’ll use (more specifically we’ll use the classic eBPF probe)\nInstalling Falco via the Google Cloud Marketplace Note: If you’d like to follow along, you’ll need to ensure your Google Cloud account has the appropriate permissions.\nInstalling Falco via the Google Cloud Marketplace is a pretty straightforward process.\nLog into your Google Cloud account, and ensure you have the required permissions to deploy a new GKE cluster or operate an existing one.\nNavigate to the Falco offering in the Google Cloud Marketplace.\nClick the configure button.\nFrom the next dialog you can choose the zone where your GKE cluster will run as well as the network and subnet on which it will run. For this walkthrough, the default values are fine.\nYou then choose whether or not you’d like to deploy Falco onto a new GKE cluster or use an existing one. Be aware that if you click Create New Cluster, Google Cloud will immediately start deploying a new cluster. Also, any Autopilot clusters that you have in your project will be grayed out and cannot be selected.\nYou can then choose which namespace Falco will run in. To keep things consistent with the rest of this blog, change it from default to falco.\nAgain, to keep things consistent with the rest of the blog, change the app instance name to falco.\nFalco rules have different priority levels, you can choose the minimum priority level you’d like to run. The priority levels are ordered by severity, and typically the higher you make the minimum level, the fewer alerts you will receive (which helps to cut down on noise). For this example just leave it as debug.\nStackdriver is the old name for Google Cloud’s logging and monitoring suite. If you’d like to examine Falco’s metrics (not the actual alerts, but metrics on how Falco is performing) you can select that option. We won’t be covering that in this blog, so go ahead and leave it unchecked.\nClick DEPLOY to deploy Falco onto the target cluster. (If you choose to deploy a new cluster, you will need to wait until that finishes to click the DEPLOY button.)\nWith that, Falco should be running on your GKE cluster. You can skip the next section, and continue with “Testing Falco”.\nInstalling Falco with Helm Helm is the defacto way to install Falco on Kubernetes. Falco maintains an official Helm chart, and that chart is maintained as part of the overall Falco project.\nIf you’d like to follow along, you will need the following:\nA Google Cloud account with appropriate permissions\nA GKE cluster that you can operate\nHelm and kubectl installed on your local computer or, alternatively, you can use Google Cloud Shell which has both Helm and kubectl already installed.\nNOTE: Ensure that your kubectl context is set to the cluster on which you wish to install Falco.\nWith the pre-requisites out of the way, let's get started with the actual install.\nAdd the Falco chart to the Helm repository.\nhelm repo add falcosecurity \\ https://falcosecurity.github.io/charts \u0026amp;\u0026amp; \\ helm repo update Create the falco namespace for Falco to run in.\nkubectl create namespace falco Use Helm to deploy Falco. Notice that we use the driver.kind parameter to set the kernel driver to the eBPF probe.\nhelm install falco \\ -n falco \\ --set tty=true \\ --set driver.kind=ebpf \\ falcosecurity/falco Wait for the Falco pods to come online.\nkubectl get pods -n falco -w Eventually you should see something similar to this:\nfalco-wfglg 2/2 Running 0 76s falco-mdrlb 2/2 Running 0 91s falco-7vxz6 2/2 Running 0 91s Note: You will see one Falco entry for each of the nodes in your cluster. In this case, Falco is running on a 3-node cluster, so there are 3 entries.\nVerify Falco is running correctly by examining the logs.\nkubectl logs -n falco -c falco -l app.kubernetes.io/name=falco You should see entries similar to this:\nFri Nov 3 15:48:07 2023: Falco version: 0.36.2 (x86_64) Fri Nov 3 15:48:07 2023: Falco initialized with configuration file: /etc/falco/falco.yaml Fri Nov 3 15:48:07 2023: Loading rules from file /etc/falco/falco_rules.yaml Fri Nov 3 15:48:07 2023: The chosen syscall buffer dimension is: 8388608 bytes (8 MBs) Fri Nov 3 15:48:07 2023: Starting health webserver with threadiness 2, listening on port 8765 Fri Nov 3 15:48:07 2023: Loaded event sources: syscall Fri Nov 3 15:48:07 2023: Enabled event sources: syscall Fri Nov 3 15:48:07 2023: Opening \u0026#39;syscall\u0026#39; source with BPF probe. BPF probe path: /root/.falco/falco-bpf.o Falco is now successfully running on your GKE cluster. The next step is to simulate some suspicious activity and verify that Falco detects it.\nTesting Falco One of Falco’s default rules fires an alert if someone shells into a running container. Follow the steps below to fire off that rule.\nStart an Alpine container and have it sleep so it stays running.\nkubectl run alpine –image alpine – sh -c \u0026#34;sleep infinity\u0026#34; Execute a shell on the Alpine running container.\nkubectl exec -it alpine -- sh -c \u0026#34;ls -al\u0026#34; Now check the Falco logs to see the alert.\nkubectl logs -c falco -n falco -l app.kubernetes.io/name=falco |\\ grep \u0026#34;Notice\u0026#34; You should see something like this:\n18:52:06.630209324: Notice A shell was spawned in a container with an attached terminal (evt_type=execve user=root user_uid=0 user_loginuid=-1 process=sh proc_exepath=/bin/busybox parent=runc command=sh -c ls -al terminal=34816 exe_flags=EXE_WRITABLE container_id=e71eac85a570 container_image=docker.io/library/alpine container_image_tag=latest container_name=alpine k8s_ns=default k8s_pod_name=alpine) Notice all the details the alert provides including the container ID, image, and name, as well as the executed command.\nConclusion As mentioned at the outset, one of the big advantages of running a managed Kubernetes service is that a lot of the heavy lifting for hardening the cluster has been done for you. However, by using Falco to provide runtime insights into the activity on your cluster you can help ensure that the cluster is being operated responsibly or has not been compromised by any bad actors.\nIf you’d like to learn more about Falco, head on over to the docs or our GitHub repository. We also have our own channel (#Falco) on the Kubernetes Slack server.\n","summary":"","tags":["Falco","GKE","Google Kubernetes Engine","Google Cloud"],"title":"Adding runtime threat detection to Google Kubernetes Engine with Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-on-gke/"},{"category":"blog","content":"This is the first of a series of weekly blog post whose aim is to give a quick overview about the development of Falco and its related projects.\nWhat happened in Falco this week? Let's go through the major changes that happened in various repositories under the falcosecurity organization.\nLibs Lots of cleanups happened in the libs repo; the most outstanding ones being:\nudig engine removal (https://github.com/falcosecurity/libs/pull/1485) dropped legacy metadata clients for k8s and mesos (https://github.com/falcosecurity/libs/pull/1478) cleaned up proc callback handling code (https://github.com/falcosecurity/libs/pull/1471) Please, note that the removal of the legacy k8s client is part of a bigger effort to entirely rewrite it as a plugin, with a more future proof architecture and language.\nSee the tracking issue: https://github.com/falcosecurity/libs/issues/987.\nAll of these cleanups account for ~26k loc removed!! :rocket:\nMoreover, some fixes landed:\nremoved some more Undefined Behavior warnings from integer copies (https://github.com/falcosecurity/libs/pull/1481) solved win32 linking issues with zlib (https://github.com/falcosecurity/libs/pull/1484) prevent libbpf stats from being collected with no bpf stats (https://github.com/falcosecurity/libs/pull/1487) Finally, some new features were merged:\nlibraries will now be properly installed under CMAKE_INSTALL_LIBDIR (https://github.com/falcosecurity/libs/pull/1101) added ppc64le experimental support for modern bpf driver (https://github.com/falcosecurity/libs/pull/1475) upgraded openssl to 3.1.4 (https://github.com/falcosecurity/libs/pull/1488) Also, we now have a target release date and a tracking issue for libs 0.14 and next driver release: https://github.com/falcosecurity/libs/issues/1482.\nFalco Now Falco builds and runs on win32 and osx too! https://github.com/falcosecurity/falco/pull/2889 While Falco won't ship for these platforms, we will now have proper CI for them.\nFollowing the huge round of cleanups in libs, k8s and mesos related configs and options were removed: https://github.com/falcosecurity/falco/pull/2914. Also, another small cleanup relative to the legacy k8saudit implementantion (not the plugin one!) was merged: https://github.com/falcosecurity/falco/pull/2913.\nFalcoctl While the code for the new driver-loader feature for falcoctl is being reviewed (part of the effort to drop falco-driver-loader script (https://github.com/falcosecurity/falcoctl/issues/327 and https://github.com/falcosecurity/falco/issues/2675), some features landed too:\nfetch config layer for a specific platform (https://github.com/falcosecurity/falcoctl/pull/349) added a new artifact manifest command (https://github.com/falcosecurity/falcoctl/pull/351) Others A new repo, k8s-metacollector, was donated to the falcosecurity.\nIt is a self-contained module that fetched metadata from kubernetes API server and dispatches them to Falco instances via gRPC.\nA new plugin is being developed to receive those metadata from gRPC, and will be shipped with Falco 0.37.\nDriverkit gained support for SUSE Linux Enterprise: https://github.com/falcosecurity/driverkit/pull/304.\nLet's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nAldo, Andrea, Federico\n","summary":"","tags":["Falco"],"title":"Falco Weekly 46 - 2023","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-w-46-2023-weekly-recap/"},{"category":"blog","content":"Detecting Cloud Runtime Threats with Falco (LFS254) is the new Falco training course created by CNCF, Linux Foundation, and Sysdig. We're very excited about this new immersive course designed to enhance your expertise in securing cloud-native applications through hands-on learning.\nDetecting Cloud Runtime Threats with Falco (LFS254) is a 20-hour course focused on runtime security. It covers what is runtime security and how Falco is a powerful tool designed to detect anomalous activity in applications. From Falco's history and design principles to its architecture, to how it addresses cloud security challenges.\nThis course is designed for IT professionals, security analysts, DevOps engineers, and anyone interested in cloud security.\nWhy? In a rapidly evolving digital landscape with a surge in cloud adoption, the importance of comprehending and deploying robust security solutions, such as Falco, cannot be overstated. Regrettably, cloud-native technologies, particularly cloud-native security, are relatively novel, and there exists a gap in knowledge and expertise for addressing these emerging challenges. Our mission is to bridge this knowledge gap and empower individuals to tackle cloud and container security complexities effectively. Through accessible training, we aspire to contribute to narrowing the talent deficit in these pivotal domains.\nHow? In this course, you'll embark on a journey of securing cloud-native environments. The course breaks down complex concepts, making them accessible and actionable. Its self-paced nature provides the flexibility to learn at your own rhythm, accommodating your personal and professional commitments. This structure allows you to digest intricate concepts and apply them bit by bit, ensuring a deeper and more lasting comprehension.\nCourse Structure The course begins with an introduction to Falco, encompassing its history, design principles, and its broader role in cloud security. It then delves into the core components of Falco, explaining its architectural design and walking you through the setup and operation of Falco. Moving forward, the course explores the significance of the system call data source in host security, offering insights into the nature of system calls, observation techniques, and best practices for efficient data collection. It further showcases Falco's versatility by examining its utilization of diverse data sources such as Github, Cloudtrail, and Kubernetes Audit logs through its Plugin Framework.\nThe course also thoroughly covers conditions and fields, delving into the realm of Falco default rules and their integration with security frameworks. It then provides comprehensive guidance on customizing Falco rules to align with specific requirements. The course also addresses Falco outputs and introduces Falcosidekick as a valuable output management and customization tool.\nFinally, the course guides you through Falco's configuration process and fine-tuning strategies. It concludes by streamlining the process of writing new Falco rules, presenting a development methodology, along with key considerations to bear in mind when crafting rules.\nSneek Peek In one of the course exercises, we explain the Log4j vulnerability and the Log4Shell exploit. We detail each step of the attack, allowing you to simulate it in the lab environment.\nThen, we walk you through how to write a new rule to detect this type of attack in Falco.\nEnroll Now Ready to embark on this transformative journey? Visit the course page to enroll and step into the world of cloud-native security mastery with Falco.\n","summary":"","tags":["Falco","Training","CNCF","Linux Foundation"],"title":"Introducing the new Falco training course, by CNCF, Linux Foundation, and Sysdig","url":"https://v0-43--falcosecurity.netlify.app/blog/new-cncf-lf-training/"},{"category":"blog","content":"Today we announce the release of Falco 0.36.2 🦅!\nFixes Falco's 0.36.2 release is a small patch addressing a few bugs. It includes the following:\nFixed a possible segfault caused by uninitialized variable in libsinsp::next() method call. (https://github.com/falcosecurity/falco/issues/2878) Improved supported program type detection for modern BPF; this ensures we can actually be sure that our BPF program type is unsupported when returning an error to the user. (https://github.com/falcosecurity/libs/pull/1404) Fixed a subtle bug in rawarg filtercheck for non-string types. (https://github.com/falcosecurity/libs/pull/1428) Fixed an uninitialized variable in the libscap bpf engine that lead to stdin getting closed while Falco soft restarted. (https://github.com/falcosecurity/libs/issues/1448) Thanks to everyone in the community for helping us in spotting these annoying bugs 🐛! You make Falco successful 🦅!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nTry it! 🏎️ As usual, in case you just want to try out the stable Falco 0.36.2, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Prefer to use a container image? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader What next? 🔮 The community is active on many topics and we hope to deliver great features and many stability fixes once again during the next release cycle!\nThe old falco-driver-loader script is showing its age and it's time to work on a more maintainable solution. falcoctl is a great candidate to host everything driver related, implement new features and make our lives easier when we need to install Falco drivers on a new machine. Our rule framework is brand new and we forsee many improvements and active development work on it. The latest Falco versions brought many improvements to the plugin framework; we wish to use those to create a more scalable Kubernetes client plugin that will be able to withstand much heavier loads and will be easier to maintain. And many, many, more enhancements!\nTo get a weekly reminder of all the great stuff happening in the Falco lands, make sure to join the #falco channel on the Kubernetes Slack!\nLet's meet 🤝 We meet every Wednesday in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions:\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nFederico\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.36.2","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-36-2/"},{"category":"blog","content":"If you’re looking to integrate runtime security into your existing environment, Falco is an obvious choice. Falco is a Cloud Native Computing Foundation backed open source project that provides real-time threat detection for cloud, container, and Kubernetes workloads. With over 80 million downloads Falco has been adopted by some of the largest companies in the world. However, what many Falco users discover early on is that Falco’s default event output is rather limited. Out of the box, Falco can only send output to five different endpoints: syslog, stdout, stderr, and gRPC or HTTPS endpoints. While these outputs might be enough to get you started, most practitioners want to integrate Falco with the tooling they already use. This is where Falcosidekick comes in. Falcosidekick is a companion (i.e. a side-kick ;)) project for Falco that allows Falco events to be forwarded to 60 different services (with more being added all the time) allowing practitioners to monitor and react to Falco events with the tools they are already using. For example, if you’d like to receive immediate notifications of suspicious activity you can forward Falco events to chat programs such as Slack or Telegram, alerting platforms like PagerDuty or AlertManager, or, of course, email. In order to minimize noise, you can expressly set the level on which to notify, for example, warning-level events might be delivered via email, while critical or higher-level events are sent via chat or directed to your alerting platform. If you want to programmatically address certain events, Falcosidekick integrates with a bunch of different services including functions as a service platforms like AWS Lambda, GCP Cloud Run and Cloud Functions, or Knative. Alerts can also be sent to message queues like Amazon SNS, Apache Kafka, or RabbitMQ. These integrations offer almost endless possibilities for building out response systems for events. For instance, let’s say you’re running Falco on your Kubernetes cluster, and Falco discovers that someone ran a program that wasn’t part of a container’s base image. In this case, you might choose to have Falcosidekick send that event over to AWS Lambda. Lambda would receive the alert and execute a function to apply a label to the pod that houses the suspect container resulting in the pod being taken out of service and a new one spawned to replace it.\nFalcosidekick can also send events to traditional monitoring and logging platforms such as Elasticsearch, Prometheus, Grafana, or Datadog (and many many others). These platforms can be used to aggregate and process alerts en masse so you can spot trends or anomalies. In addition to looking at the actual Falco events, Falcosidekick also provides metrics on its own performance. There are also service endpoints to check if Falscosidekick is running and its general health. Falcosidkick features its own web-based user interface to get a quick view into your Falco environment. This UI offers reporting on Falcosidick’s performance metrics as well as a feed for events reported by the connected Falco instances.\nIf you want to archive Falco events, Falcosidekick can send them to Redis or various object storage services like AWS S3 or Google Cloud Storage. Falcosidekick runs as a daemon and can be easily installed via multiple mechanisms including as a Docker container, or via Helm. With Helm, you can either install Falcosidekick when you install Falco or add it to your environment later. From an architectural standpoint, Sidekick is deployed to two pods to help ensure high availability and a single Sidekick instance can receive events from multiple Falco environments. With so many different options, Falcosidekick opens up a myriad of possibilities for integrating Falco’s runtime security capabilities into your existing tooling. If you’d like to try Falcosidekick yourself, check out Thomas’ blog post which covers how to integrate Falcosidekick with Slack. And, if you’d like to get involved with Falco or Falcosidekick come chat with us over on the #Falco channel in the Kubernetes Slack or check out the Github repos.\n","summary":"","tags":["tool"],"title":"Integrate Runtime Security into Your Environment with Falcosidekick","url":"https://v0-43--falcosecurity.netlify.app/blog/integrate-runtime-security-with-falcosidekick/"},{"category":"blog","content":"Falco v0.36.0 and the Software Supply Chain (SSC) security The latest stable Falco release, v0.36.0, alongside falcoctl 0.6.1 and the 0.7.0 Helm chart introduced new features and improvements to the security of Falco's software supply chain artifacts. Falco's two main downloadable artifacts are plugins and rule sets. They're shipped in the OCI specification format and distributed through the official Falcosecurity OCI repositories.\nSoftware supply chain attacks aim at injecting malicious code into software components, to compromise downstream users. These types of attacks are among the primary threats in today's threat landscape.\nIn particular, attackers abuse trust relationships existing between the different open-source stakeholders. The increase in attacks on open-source software throughout the last few years demonstrates that attackers consider them a viable means for spreading malware.\nSSC safeguards Securing the software supply chain may seem daunting at first glance, but there are a lot of safeguards that can be put in action. And there are ways to categorize them, and ways to prioritize them.\nSafeguards against supply chain attacks can be classified by control type: directive, preventive, detective, corrective, and recovery. But there ain't no such thing as a free lunch. Besides safeguard classifications, the utility-to-cost ratio can also be an important factor in deciding where to start in improving the supply chain security of software, and can be pretty easy to measure it.\nThere are cheap preventive safeguards that can be implemented in open source projects especially, where stakeholders platea can be pretty wide considering the contributions. For example, branch protection rules are usually simple per-code repository configurations in providers (e.g. GitHub) and alongside pull request-based flows enforcing code review quorum, are also standard best practices nowadays. The same applies to reproducible builds, dependency pinning, build steps isolation, MFA authentication to repository providers, etc.\nOn the other side, safeguards with a high utility value can require a considerable amount of effort to be implemented end-to-end (producer and consumer sides).\nMITRE and OpenSSF increased their efforts to improve SSC security recently in general and in the open source, by providing frameworks and tools that increase the utility-to-cost ratio. MITRE for example proposes an end-to-end framework to preserve the integrity of the software supply chain. OpenSSF develops the SLSA framework that groups several security best practices for open-source projects.\nMoreover, the in-toto Attestation Framework defines a fixed, lightweight Statement that communicates some information about the execution of the software supply chain, such as if the source was reviewed, or if it went through a SLSA conformant build process.\nBecause new attacks are being introduced almost every day, It's important to be constantly evolving your SSC security tools and processes. These safeguards should be placed as early as possible in the SSC (\u0026quot;shift left\u0026quot;). Additionally, they need to be continuously maintained in order to keep pace with attacker's efforts.\nThanks to important projects like Sigstore's cosign, software artifact signatures are one of the SSC safeguards with a high utility-to-cost ratio. Due to these factors, the Falco Software Supply Chain Working group decided to make implementing these signatures a goal for the Falco project\u0026quot;\nArtifacts distributed as OCI Since January 2023 we started distributing Falco plugins and rules as OCI artifacts. If you are not familiar with the concept, think about OCI artifacts as a content-addressable unit of data that can be tagged, stored and indexed in container registries alongside your container images but can hold any type of file. You can find the source and the data for Falco's artifacts in the plugins and rules repositories respectively. We are using GitHub Container Registry to publish them so you can find them in the \u0026quot;Package\u0026quot; section of each repository.\nPackaging Falco's rules and plugins as container artifacts brings several advantages, such as:\nWe can create multiple tags, both fixed and floating, for each artifact. Keeping track of the latest version is easy as well as the latest version for each major and minor release. Distribution is handled with a standard protocol implemented by many different container registries, which means that creating your own rules registry, either public or private, is easy and you can use your existing container distribution infrastructure (or any ready-to-use registry service as offered by all major cloud providers) without installing and maintaining any custom server. There are standard and developing mechanisms and specifications to store artifact metadata, like link between artifacts for references to signature or Software Bill Of Materials (SBOM), so we do not need to reinvent the wheel. In falcoctl we have used the CNCF ORAS library to manage downloading and uploading artifacts to the container registry.\nCosign keyless signing and verification Another very interesting thing you can do with OCI artifacts is now sign them thanks to cosign! Cosign supports a very interesting mechanism called keyless signing. This allows us to perform artifact signature and verification without the need for creating, maintaining and securing long-lived and opaque signing keys.\nMoreover, cosign supports OCI v1.1 being able to link security artifacts through OCI references when supported by the registry.\nImplementation Release pipelines for signed plugins and rules Plugins and rules that we sign are packaged as OCI artifacts.\nAs for the diagram above, there are two distinct distribution pipelines: one is to update the general Falcoctl index and one is to distribute the single artifact, whether plugin or rule set, to the OCI registry.\nContainer registry update At the same time, in the release pipeline, an OCI artifact is built with a specific build tool for each artifact updated, and a signature is generated and distributed to the registry for each one. The signature is generated with the help of Cosign using the keyless mode, which leverages OIDC with GitHub as the identity provider.\nIn-depth: as the pipeline is a non-interactive environment, cosign automatically uses the OIDC device flow to verify the Github action identity token and generates a certificate as proof of the identity of the user that is signing the artifact. Cosign generates a transparency log object that contains the hash of the artifact, the previously generated certificate's public key, and the signature. This object can be verified against the signature, certificate, and artifact pulled from the OCI registry.\nFor example, you can check with the cosign CLI that a valid signature for the plugin cloudtrail is available:\n$ cosign tree ghcr.io/falcosecurity/plugins/plugin/cloudtrail:latest 📦 Supply Chain Security Related artifacts for an image: ghcr.io/falcosecurity/plugins/plugin/cloudtrail:latest └── 🔐 Signatures for an image tag: ghcr.io/falcosecurity/plugins/plugin/cloudtrail:sha256-ec47c7448d455b6bb84f39d5c400c2fa207ab5fbe8c21327c6c1d06a3f1eecb4.sig └── 🍒 sha256:f8aae8441b2d41419ae99d4979d6eab1543d81a269e4721fdbff0d837571aa4d And you can inspect with the oras CLI its manifest, by taking the tag that contains the digest content identifier of the artifact signed (i.e. ghcr.io/falcosecurity/plugins/plugin/cloudtrail:sha256-ec47c7448d455b6bb84f39d5c400c2fa207ab5fbe8c21327c6c1d06a3f1eecb4.sig):\n$ oras manifest fetch ghcr.io/falcosecurity/plugins/plugin/cloudtrail:sha256-ec47c7448d455b6bb84f39d5c400c2fa207ab5fbe8c21327c6c1d06a3f1eecb4.sig | jq { \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.config.v1+json\u0026#34;, \u0026#34;size\u0026#34;: 242, \u0026#34;digest\u0026#34;: \u0026#34;sha256:ef254edd0dd0ae2b9b6ef0471c915682c0ba31858fe45bc817a951cad715fe8d\u0026#34; }, \u0026#34;layers\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.dev.cosign.simplesigning.v1+json\u0026#34;, \u0026#34;size\u0026#34;: 263, \u0026#34;digest\u0026#34;: \u0026#34;sha256:f8aae8441b2d41419ae99d4979d6eab1543d81a269e4721fdbff0d837571aa4d\u0026#34;, \u0026#34;annotations\u0026#34;: { \u0026#34;dev.cosignproject.cosign/signature\u0026#34;: \u0026#34;MEUCIGvgIIu9JX5vVCZ5YHsoVe3wpVoIianJvzkCZUIClVlAAiEAyx7GZztNDzCJN5Fjg8vwq0pv7PH3TrseIXN1ou35Jmw=\u0026#34;, \u0026#34;dev.sigstore.cosign/bundle\u0026#34;: \u0026#34;{\\\u0026#34;SignedEntryTimestamp\\\u0026#34;:\\\u0026#34;MEYCIQDsAPhTbHc7w+LHpipbx0HSEIlmjjbAszF5ChHRO1jyKgIhAJrDmeLtzO72fGD1WHabY8Mwz7Qph9CzDg+EMkC9JR7A\\\u0026#34;,\\\u0026#34;Payload\\\u0026#34;:{\\\u0026#34;body\\\u0026#34;:REDACTED}}\u0026#34;, \u0026#34;dev.sigstore.cosign/certificate\u0026#34;: \u0026#34;-----BEGIN CERTIFICATE-----\\nREDACTED\\n-----END CERTIFICATE-----\\n\u0026#34;, \u0026#34;dev.sigstore.cosign/chain\u0026#34;: \u0026#34;-----BEGIN CERTIFICATE-----\\nREDACTED=\\n-----END CERTIFICATE-----\\n-----BEGIN CERTIFICATE-----\\nREDACTED\\n-----END CERTIFICATE-----\u0026#34; } } ] } You can see that it contains a layer of type application/vnd.dev.cosign.simplesigning.v1+json. Also, its annotation metadata helps cosign to authenticate the signature against the Sigstore's Rekor transparency log.\nIndex update Each artifact type has its own registry metadata file. The general falcoctl index.yaml, which refers to all artifact types, is updated when a modification to the specific artifact type metadata occurs. In order to verify a keyless signature we need to know in advance some additional metadata about the type of signature and how to verify its authenticity. We are adding this data to the registry metadata so that it can be published to the index by the pipeline. We will see this content in the next section.\nTransparent signature verification in falcoctl We have seen that every artifact now has signature data available. This is nice, but to complete this feature we need to make sure that the signature data is automatically checked when we download an artifact. In the same way, package signatures are verified when you run apt-get install, falcoctl needs to do the same to the OCI artifacts it downloads.\nWhen designing this feature we decided not to change the existing usage of falcoctl. For example, you may already know that when you decide to install a new apt repository you need to also import its public key. When installing Falco artifacts with falcoctl, we can avoid this step and make verification transparent, thanks to keyless signing by trusting the Sigstore Fulcio CA. In the section above we introduced the concept of index files. Every time you use falcoctl, there is an index file that tells details about artifacts distributed by the Falco organization. For instance, the cloudtrail plugin has an entry with several pieces of metadata, including the OCI artifact coordinates: ghcr.io/falcosecurity/plugins/plugin/cloudtrail. Of course, anyone can distribute and install their own index file for their plugins and rules.\nWhat we have recently added is the signature part:\nsignature: cosign: certificate-oidc-issuer: https://token.actions.githubusercontent.com certificate-identity-regexp: https://github.com/falcosecurity/plugins/ This section indicates how to check the signature for this artifact. This way the index file contains information on how to download and how to verify the artifact.\nUpon request to install the artifact falcoctl is going to check the index file, resolve the name, identify the digest from the registry, pull the signature, and validate it by using cosign as a library. Only once the signature is verified, falcoctl will allow the installation of the plugin with that specific digest. If the signature data does not match the installation will be halted with an error.\nYou can try it yourself to make sure that the signature works!\nsudo docker run -it --entrypoint sh falcosecurity/falcoctl:0.6.1 # falcoctl artifact install cloudtrail:0.9 --rulesfiles-dir=/tmp --plugins-dir=/tmp But there is more! If you have cosign installed you can independently verify the signature without using falcoctl or any index file:\n$ cosign verify ghcr.io/falcosecurity/plugins/plugin/cloudtrail:0.9.0 --certificate-oidc-issuer=https://token.actions.githubusercontent.com --certificate-identity-regexp=https://github.com/falcosecurity/plugins/ Verification for ghcr.io/falcosecurity/plugins/plugin/cloudtrail:0.9.0 -- The following checks were performed on each of these signatures:\nThe cosign claims were validated Existence of the claims in the transparency log was verified offline The code-signing certificate was verified using trusted certificate authority certificates [...] This is one of the main advantages of relying on widely adopted container artifacts signing technologies of the cloud native world. Authentication of the artifacts is decoupled from the producer, and consumers can always choose the method they prefer.\nSecurity Analysis With the above scheme, we made steps forward and implemented best practices towards better supply chain security in the Falco ecosystem. We would like to conclude our discussion with the main takeaways for a security practitioner.\nSafeguards against registry tampering, secure by default Making use of container registries to distribute artifacts is convenient, and allows for easy replication of the data across multiple regions or providers. But even if one of those registries is at risk of being compromised , clients will be protected from potentially malicious applications. If an artifact is replaced in the registry without going through the appropriate approval and open source release pipeline, clients will identify that the signature does not match and automatically refuse to install any compromised package. This is only possible because cosign signature information is distributed in a file that is separate from the artifact itself. With falcoctl 0.6.1 this feature is on by default and requires no extra action from users.\nIndependent signature verification It is now possible for all Falco rules and plugins users to independently verify the authenticity of every artifact they download. We implemented this feature staying true to the open nature of Falco, so by design, you do not need any Falco-specific tool (like falcoctl) to verify your artifact and you can do it manually with cosign to implement even tighter controls.\nAttack surface As security practitioners, we should always analyze the attack surface of the security schemes we design and update our threat model accordingly. In this case, we can identify that:\nIf the source repositories are compromised, so will the packages. Of course, the open-source repositories act as the single source of truth for our plugins and rules. If an attacker manages to merge malicious code and release a malicious plugin they will be able to compromise users once they update or install a new version. Release pipelines are the only component that can generate a proper signature for the artifacts. If the index file is compromised, so will the packages. The index file maps artifact names (e.g. cloudtrail) to their location in the container registry (e.g. ghcr.io/falcosecurity/plugins/plugin/cloudtrail). If that entry is modified to point to an attacker-controlled registry, possibly alongside an attacker-controlled signature, clients will download a potentially malicious artifact instead of the official one. At this point in time, the entire infrastructure is hosted by GitHub, making it a potential single point of failure and an entity that the Falco project completely trusts. However, even if parts of the infrastructure (container registry, CDN for index distribution, ...) were not, GitHub release pipelines would still have permissions or access tokens to operate those locations. Let's keep in touch Security is a never ending effort, and supply chain security is no exception. Falco maintainers and community are committed to keep improving all security aspects of the Falco project.\nWe'll keep you up to date with the next steps and remember, if you want to be involved you're more than welcome, don't hesitate to reach out to the community and the Falco Software Supply Chain Security Working Group in the #falco-sscs-wg Slack channel in the CNCF workspace.\n","summary":"","tags":null,"title":"How we Sign and Verify Falco Plugins and Rules","url":"https://v0-43--falcosecurity.netlify.app/blog/sign-verify-plugins-rules/"},{"category":"blog","content":"Today we announce the release of Falco 0.36.1 🦅!\nFixes Falco's 0.36.1 release is a small patch aimed at protecting our uses by addressing a few minor bugs. It includes the following:\nAddress a HIGH severity vulnerability in libcurl CVE-2023-38545, bumping the library to the patched version 8.4.0. You can find more details in the section below. The legacy eBPF probe can now handle systems with CPU hotplug enabled, opening the right number of kernel buffers. (https://github.com/falcosecurity/falco/issues/2843) Remove a no longer useful experimental Falco config outputs_queue.recovery. This was introduced in Falco 0.36.0 as an experiment. Fix a possible segfault caused by a faulty implementation of timer_delete. (https://github.com/falcosecurity/falco/issues/2850) Thanks to everyone in the community for helping us in spotting these annoying bugs 🐛! You make Falco successful 🦅!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nVulnerability in libcurl A HIGH severity vulnerability in libcurl, CVE-2023-38545, was disclosed alongside a patched version (8.4.0). We would like to answer the main question you might have about it: Does it affect Falco?\nAccording to the excellent in-depth description of the bug, this can only be triggered if both conditions below are true:\nA SOCKS5 HTTP(S) proxy has been configured. This happens if you have set the standard environment variables that control proxy connections, such as http_proxy/https_proxy/no_proxy or libcurl-specific ones as indicated in the advisory or the libcurl documentation. An attacker controls the server that Falco is connecting to, namely the server configured to receive http_output or a custom prebuilt driver repository server, and the SOCKS5 proxy is \u0026quot;slow enough\u0026quot; to allow the attack to happen. While it may be rare that users have an exploitable environment, it's still a possibility. For this reason, Falco maintainers decided to ship this patch release 🦅\nTry it! 🏎️ As usual, in case you just want to try out the stable Falco 0.36.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Prefer to use a container image? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader What next? 🔮 The community is active on many topics and we hope to deliver great features and many stability fixes once again during the next release cycle!\nThe old falco-driver-loader script is showing its age and it's time to work on a more maintainable solution. falcoctl is a great candidate to host everything driver related, implement new features and make our lives easier when we need to install Falco drivers on a new machine. Lately we have expanded the syscall coverage that Falco can provide. We wish to improve these efforts across all drivers with even more 32 bit syscalls. Our rule framework is brand new and we forsee many improvements and active development work on it. The latest Falco versions brought many improvements to the plugin framework; we wish to use those to create a more scalable Kubernetes client plugin that will be able to withstand much heavier loads and will be easier to maintain. And many, many, more enhancements!\nLet's meet 🤝 We meet every Wednesday in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nAndrea, Luca\n","summary":"","tags":["Falco","Release"],"title":"Introducing Falco 0.36.1","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-36-1/"},{"category":"blog","content":"Falco, an open source innovation, was conceived with the vision of crafting a flexible and robust rules engine atop the Sysdig libraries. This initiative aimed to furnish a potent tool for the detection of aberrant behaviors and intrusions within modern applications, akin to the Snort paradigm but tailored to the realm of system calls and finely tuned for cloud environments.\nNevertheless, it's important to recognize that Falco and Wireshark represent distinct facets of this evolutionary process. Falco offers ongoing surveillance akin to Snort, while Wireshark specializes in interactive endpoint network traffic analysis.\nThe Need for Modern System Introspection Part of this journey has been the emergence of cloud native apps. From the early days of BPF (Berkley Packet Filter) and libpcap (a portable C/C++ library for network traffic capture), which laid the foundation for network packet analysis, to the familiar graphical user interface of Wireshark, our understanding of network data has undergone profound changes. This article embarks on a journey through this transformation, shedding light on how tcpdump and libpcap sparked an explosion of packet-based analysis and runtime security tools exemplified by Wireshark and Snort.\nWireshark, Snort, Nmap, Kismet, ngrep, and a bunch of other tools started at around the same time and are all evolutionary branches of tcpdump and libpcap.\nHowever, as cloud computing continues to reshape the technological landscape, traditional network packet analysis tools have found themselves grappling with an evolving challenge: the cloud itself. Cloud native applications have ushered in a new era of complexity and dynamism, rendering many existing visibility solutions obsolete. This shift necessitated a fresh perspective on network monitoring, leading to the birth of Falco, a tool poised to be the Snort of the cloud.\nStarting the story with Network Packet Analysis During the late 1990s Internet boom, the demand for computer networks skyrocketed, leading to an increased need for monitoring, troubleshooting, and securing these networks. Regrettably, the available network visibility tools of that era were prohibitively expensive for many operators, leaving them grappling with a lack of insights.\nConsequently, teams worldwide embarked on a mission to address this predicament. Their efforts revolved around expanding existing operating systems to incorporate packet capture capabilities, essentially transforming off-the-shelf computer workstations into devices capable of residing on a network and capturing all inbound and outbound data packets from other workstations. One such solution was the Berkeley Packet Filter (BPF), crafted to extend the functionality of the BSD (Berkeley Software Distribution) operating system kernel.\nFor Linux users, the term 'eBPF' may ring a bell – a virtual machine renowned for securely executing arbitrary code within the Linux kernel. Remarkably, eBPF has evolved into a powerful and flexible technology over the years. However, its origins trace back to a modest programmable packet capture and filtering module designed for BSD Unix.\nThe BPF team introduced a game-changing library known as 'libpcap,' which enabled any program to capture raw network packets. It was developed in order to make tcpdump more useful. For instance, it gave the ability to filter packets. Since then, a bunch of spin-off networking projects would emerge on the scene. In 1998, a GUI-based open source protocol analyzer named 'Ethereal' (later renamed Wireshark) was introduced, eventually becoming the gold standard in packet analysis that persists to this day. \\\nWhat unites 'tcpdump,' Wireshark, and numerous other popular networking tools is their ability to access a data source that is rich, accurate, and reliable, all collected in a nonintrusive manner: raw network packets. This fundamental concept will be central to our discussion moving forward.\nThe evolution of Packet-Based Intrusion Detection Systems Introspection tools, such as tcpdump and Wireshark, naturally emerged as the initial applications harnessing the capabilities of the BPF packet capture stack. However, as time progressed, innovative applications for packet data began to surface. Enter Snort, an open source, packet-based runtime security tool that shares common ground with Falco. Much like Falco, Snort operates as a rule engine, processing packets acquired from network traffic. Like its cloud native counterpart, Snort boasts an extensive library of pre-configured rules designed to identify threats and unwarranted activities by scrutinizing packet content, protocols, and payload data. The success of Snort served as a catalyst for the development of similar tools, including Suricata and Zeek.\nWhat truly empowers tools like Snort is their proficiency in assessing the security of networks and applications in real time, even as these applications run. This real-time focus proves invaluable by delivering immediate protection with a unique emphasis on runtime behavior, enabling the detection of threats rooted in vulnerabilities that may remain undisclosed.\nThe issue with Network Packet Capture in the Cloud The utilization of network packets as a foundational data source has spawned a thriving ecosystem. Nonetheless, several emerging trends have gradually eroded the viability of packets as an unequivocal source of information.\nFirst, the task of comprehensively collecting packets has grown increasingly complex, especially within environments such as the cloud, where access to routers and network infrastructure is constrained. Second, the proliferation of encryption and network virtualization has posed formidable challenges in extracting valuable insights from network traffic. Lastly, the ascent of containerization and orchestrators like Kubernetes has rendered infrastructures more elastic while concurrently complicating the reliable collection of network data.\nOnce again, a dynamic new ecosystem was unfolding, yet the means to effectively troubleshoot and secure it remained elusive.\nSystem Calls are the New Network Packets Before the emergence of Falco, an open source tool known as 'Sysdig Inspect' was crafted with a primary focus on the collection of packet data within cloud native ecosystems. This was achieved through the capture of system calls, often referred to as syscalls, originating from the kernel of the operating system.\nSyscalls, as a data source, offer a richness that surpasses that of mere network packets. They encompass a wide spectrum of activities, extending beyond network data to encompass file I/O operations, command executions, interprocess communication, and more. Syscalls stand out as an ideal data source for cloud native environments as they can be harnessed from the kernel, catering to both containerized environments and cloud instances. Moreover, the process of collecting syscalls is characterized by its simplicity, efficiency, and non-invasiveness.\nThe architecture of Sysdig comprised a kernel capture probe, making use of either the default, loadable kernel module or leveraging eBPF. To facilitate the development of capture programs, Sysdig offered a suite of libraries, enabling seamless integration with modern cloud native technologies such as Kubernetes and various orchestrators. This versatility addressed the shortcomings observed in environments where traditional solutions like Snort and Wireshark fell short. Additionally, Sysdig provided a command-line tool replete with decoding and filtering functionalities, tailored to accommodate the prevalent network packet workflows essential in cloud environments, where the ease of filtering and scriptability of trace files is paramount.\nFalco - the evolution of Wireshark to the Cloud Drawing from our comprehension of how Snort introduced a rule-based engine for scrutinizing network traffic to identify suspicious activity, an evolution that implemented Wireshark's network introspection, and how Sysdig expanded the scope of visibility within cloud native environments by delving into system calls, effectively departing from sole reliance on Wireshark's libpcap framework. It logically followed that an Intrusion Detection System (IDS) solution would emerge, featuring a sophisticated rule-based engine tailored for cloud native workloads while harnessing the capabilities of eBPF and the kernel's system call architecture.\nFalco's rule engine drew inspiration from Snort's design but operated within a far more expansive and versatile dataset, seamlessly integrated with the Sysdig libraries. While its default ruleset may be more concise than Snort's, Falco empowers users to craft intricate rules that trigger in real-time based on arbitrary contextual factors. These factors encompass a wide array of scenarios, including access to sensitive data, mode transitions, unexpected network connections, socket alterations, compliance breaches, and more. Given its capacity to monitor all activities on a server or node through system calls, Falco functions as a real-time intrusion detection tool, mirroring Wireshark's role in providing real-time network analysis for endpoints.\nFalco for Cloud Native Security In the journey from the early days of BPF to the widespread adoption of Wireshark, we've witnessed the remarkable evolution of system introspection tools, each one contributing to the ever-expanding landscape of cybersecurity. However, as cloud native computing and microservices architectures become the new norm, a new champion has emerged: Falco. Falco represents the cutting edge of intrusion detection, specifically designed to tackle the intricacies and challenges posed by cloud native hosts and workloads. With its real-time behavioral monitoring, container awareness, and comprehensive rule sets, Falco stands as a testament to the adaptability and innovation in the world of cybersecurity. As the digital landscape continues to evolve, Falco is the tool of choice for those who prioritize the security and integrity of their cloud native environments. It's not just a system introspection tool; it's the future of protecting what matters most in this rapidly changing world of technology.\nIf you want to try out Falco, check out our Getting Started documentation. Join our community at #falco channel within Kubernetes Slack.\n","summary":"","tags":["Falco","Wireshark","Linux"],"title":"Linux Introspection - From BPF to Wireshark to Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/wireshark-to-falco/"},{"category":"blog","content":"Introduction In Tracing System Calls Using eBPF Part 1, we lay the groundwork, introducing you to the fundamentals of eBPF and its predecessor, BPF (Berkeley Packet Filter). We delve into the evolution of this technology, its safety, performance, and observability advantages over traditional kernel modules, and its pivotal role in securing modern cloud native environments. We guide you through the intricate process of working with eBPF programs, from compilation to execution, highlighting its power in tracing system calls.\nIn the second installment, Tracing System Calls Using eBPF Part 2, we elevate our understanding of eBPF's capabilities. We unravel the world of Uprobes and Uretprobes, demonstrating how these features empower developers to instrument and monitor user-space applications seamlessly. We then venture into Kprobes and Kretprobes, unlocking the potential to dynamically trace and debug kernel functions, offering insights into system behavior and performance analysis.\nUprobes Uprobes, short for user probes, are a feature in the Linux kernel that enables developers to instrument and monitor user-space applications without modifying their code directly. They allow for the insertion of breakpoints at specific points of interest within an application, facilitating the collection of data, tracing of function calls, debugging, and performance analysis.\nUretprobes Uretprobes, short for User Return Probes, are a feature in the Linux kernel that allows developers to trace and monitor the return paths of functions in user-space applications. While uprobes are used to instrument and intercept the entry points of functions, URETprobes specifically focus on the exit points or return paths. They enable developers to set up probes that are triggered when a specific function returns to its caller.\nHere is an eBPF program that uses user probes to trace the printf function present in glibc (the standard GNU C Library).\nIn accordance with the instructions outlined in our Tracing System Calls Using eBPF Part 1 blog, we can create a loader to effectively load this eBPF program and read the logs from the file /sys/kernel/tracing/trace_pipe .\nKprobes Kprobes, short for Kernel Probes, are a feature in the Linux kernel that allow dynamic tracing and debugging of kernel functions. They are particularly useful for tasks like performance analysis, bug diagnosis, and system monitoring. They provide a non-intrusive way to gather runtime information from the kernel without requiring modifications to the kernel code itself. Additionally, they can be used to trace specific function calls, track parameters and return values, and gather statistical data on function execution\nKretprobes Kretprobes, short for Kernel Return Probes, are a feature in the Linux kernel that complements Kprobes by allowing dynamic tracing and debugging of kernel function return points. While Kprobes focus on probing the entry points of kernel functions, kretprobes specifically target the return points of these functions.Similar to Kprobes, kretprobes work by inserting a probe handler function that gets executed when a specific kernel function is about to return. This allows developers and system administrators to gather information, modify return values, or perform additional actions at the point of function return.\nHere is an eBPF program that uses kernel probes to trace a kernel function named prepare_kernel_cred. This function is used to create a new struct cred object that represents the credentials or privileges associated with a kernel task. It is commonly used in privilege escalation exploits for gaining root access. By tracing this function, we can identify all processes that invoke it, providing valuable insight for analyzing potential malicious activity.\nSEC(“kprobe/prepare_kernel_cred”) indicates that an eBPF program is associated with the kprobe event for the \u0026quot;prepare_kernel_cred\u0026quot; kernel function. This event allows dynamic tracing and debugging by intercepting the entry point of the function.\nstruct pt_regs is a data structure that provides access to the register state of the program when it is executed. It contains information about the CPU registers at the time of the eBPF program invocation. It is defined as :\nTo facilitate the loading of the aforementioned eBPF program, we’ll use the following program.\nHere is a Makefile for compiling the eBPF program and the loader\nConclusion In this two-part exploration of Tracing System Calls Using eBPF, we've embarked on a fascinating journey through the inner workings of this powerful technology. Part 1 laid the foundation by introducing us to the fundamentals of eBPF and its predecessor, BPF, shedding light on their evolution and significance in modern cloud native environments. We uncovered how eBPF's safety, performance, and observability advantages empower us to trace system calls with unmatched efficiency.\nIn Part 2, we took our understanding to new heights. We delved into the world of Uprobes and Uretprobes, showcasing how they enable seamless instrumentation and monitoring of user-space applications. We then ventured into Kprobes and Kretprobes, unlocking the ability to dynamically trace and debug kernel functions. Armed with these advanced techniques, we gained valuable insights into system behavior, performance analysis, and even the detection of potential malicious activity.\nAs we conclude this journey into the heart of eBPF, we stand equipped with a powerful set of tools and knowledge. Whether you're a seasoned sysadmin, a curious developer, or a vigilant security enthusiast, the capabilities of eBPF open new doors to real-time monitoring and analysis.\nStay tuned for further insights and practical guidance in the world of eBPF, where innovation meets security, and the future of system monitoring becomes a reality.\n","summary":"","tags":["eBPF","Falco","Syscalls","Probes"],"title":"Tracing System Calls Using eBPF - Part 2","url":"https://v0-43--falcosecurity.netlify.app/blog/tracing-system-calls-using-ebpf-part-2/"},{"category":"blog","content":"Dear Falco Community, today we are happy to announce the release of Falco 0.36.0!\nThis releases comes as usual with many new features and improvements. Thanks to everyone that worked on all the features, bugfixes and improvements! To read a detailed account of the release, see v0.36.0 in the changelog.\nDuring this release cycle, we merged more than 100 PRs on Falco and more than 150 PRs for libs and drivers, version 0.13.1 and version 6.0.1 respectively. Thank you to our maintainers and contributors, as this would not happen without your support and dedication!\nThis release comes with many brand new features, some long awaited UX improvements and configuration and also beware of some breaking changes! Don't worry, everything is explained below!\nWhat's new? TL;DR In release v0.36.0, we focused on the following features:\nBrand new Falco rule framework and ruleset More robust executable file path detection, symlink resolution and ancestors detection Falco is no longer limited to one rule firing per event! Signatures are now automatically verified in Falcoctl for plugins and rules Upgrade of the default Falco images We have also some massive experimental upgrades that the community has spent incredible amounts of effort on:\nWASM support Kernel driver testing at scale! Falco now has an experimental distroless container image based on Wolfi Breaking changes ⚠️ We have seen many requests from the community in the form of questions and issues. Those are the ones that shape the evolution of Falco, so we can hopefully make the user experience better at every release. Sometimes, in order to do this we need to implement changes that may impact some workflows. In this release we have important breaking changes you should be aware of:\nThe default rules file that is shipped in the Falco image and/or can be downloaded via falcoctl as falco-rules is now a stable rule file. This file contains a much smaller number of rules that are less noisy and have been vetted by the community. This serves as a much requested \u0026quot;starter\u0026quot; Falco rule set that covers many common use case. The rest of that file has been expanded and split into falco-incubating-rules and falco-sandbox-rules. Read more below to learn about the difference. The main falcosecurity/falco container image and its falco-driver-loader counterpart have been upgraded. Now they are able to compile the kernel module or classic eBPF probe for relatively newer version of the kernel (5.x and above) while we no longer ship toolchains to compile the kernel module for older versions in the default images. Downloading of prebuilt drivers and the modern eBPF will work exactly like before. The older image, meant for compatibility with older kernels (4.x and below), is currently retained as falcosecurity/falco-driver-loader-legacy. The Falco HTTP output no longer logs to stdout by default for performance reasons. You can set stdout logging preferences and restore the previous behavior with the configuration option http_output.echo in falco.yaml. The --list-syscall-events command line option has been replaced by --list-events which prints all supported system events (syscall, tracepoints, metaevents, internal plugin events) in addition to extra information about flags. The semantics of proc.exepath have changed. Now that field contains the executable path on disk even if the binary was launched from a symbolic link. The -d daemonize option has been removed. The -p option is now changed: when only -pc is set Falco will print container_id=%container.id container_image=%container.image.repository container_image_tag=%container.image.tag container_name=%container.name when -pk is set it will print as above, but with k8s_ns=%k8s.ns.name k8s_pod_name=%k8s.pod.name appended Command line options s and stats-interval have been removed in favor of metrics config in falco.yaml. Major features and improvements New Falco rules framework 🛡️ This project is the result of a discussions that started a long time ago and required a massive amount of work from the community. Following this proposal we have decided to split the rules that the Falco community maintains into three main groups, described in the maturity levels section of the contributing guide:\nStable Falco rules. Those are the only ones that are bundled in the Falco by default. It is very important to have a set of stable rules vetted by the community. To learn more about the criterias that are required for a rule to become stable, see the contributing guide Incubating rules, which provide a certain level of robustness guarantee but have been identified by experts as catering to more specific use cases, which may or may not be relevant for each adopter. Sandbox rules, which are more experimental. It is important to keep in mind that the stable ruleset is significantly changed since the last release! Not only the rules are a much smaller subset but they have been refined and they may have been renamed according to the style guide.\nThanks to Melissa Kilby for driving this effort 🚀!\nThe list of releases for each type of rule is present in the repository, where you can download each file. They can also be downloaded from the download page and are also available as signed OCI artifacts for download via falcoctl!\nWant to contribute to the rules? You can find more information in the contribution guide and the style guide.\nProcess executable and lineage 🪪 We have achieved a higher level of accuracy and data quality regarding the existing proc.exepath field and the process tree reconstruction in general. This step forward reinforces our commitment to refining Falco and providing you with an even better user experience.\nIn more detail:\nThe proc.exepath process executable path field now contains a resolved version of the executable path, meaning that even if an executable was launched from a symlink, the field will show the original location of the binary. In the past, we resolved the exe argument in userspace by utilizing the process's cwd when the path was not absolute. Conversely, if exe was absolute, the exepath was equivalent to exe. The new implementation ensures the extraction of the authentic and accurate disk path of the executable when it resides on the disk. As it turns out, it's not that simple to reconstruct the complete process tree in a Linux system. The Linux kernel presents intriguing edge case behaviors, where the direct parent process might genuinely have already exited. In the past, Falco encountered difficulties in continuing to reconstruct the parent process lineage in such situations. To address this, we've enhanced Falco's logging capabilities. Now, even in scenarios where the parent process has exited, Falco can continue reconstructing the process tree. Container image changes 📦 We have two big changes to our default container images:\nThe falco-driver-loader image is now based on Debian Bookworm with a more modern version of compilers, meaning that it will be much easier to build on contemporary systems but you might see compilation issues for older kernels (4.x and below). For that, the falco-driver-loader-legacy image is provided! Also, this means that vulnerability scanners will not report so many false positive vulnerabilities in the new version of the image since it does not contain legacy versions of compilers. We have a falco-distroless image based on Wolfi, thanks to contributions from Adrian Mouat and the Falco Supply Chain Security WG! This is for all of you that are fans of minimal images! You can try it out by replacing falco-no-driver with falco-distroless. Falcoctl ❤️ cosign Since Falco 0.35.0 we started providing signed official container images signed with cosign in keyless mode. But how about our other OCI artifacts, which are rules and plugins? Starting from Falcoctl 0.6.1, shipped with this release, all of the official rules and plugins are signed and automatically verified at installation time thanks to the magic of cosign in keyless mode!\nThanks to Massimiliano Giovagnoli for his help along with the Falco Supply Chain Security WG! Stay tuned for an in-depth explanation of the security architecture of this feature.\nMultiple rules can be matched on each event Pro Falco users know that we could only match one rule for each event. This is not true anymore, and since this version we have a rule_matching option in the configuration file. rule_matching: all will remove this limitation and match everything. See the documentation in falco.yaml for more information!\nBig experimental contributions Last but not least, we have several big projects that we have started with the community and are very proud of.\nFalco Kernel Testing Framework Falco supports a large number of Linux kernels. And the truth is, in order to test this kind of functionality you have to start an (ideally) equally large number of live Linux systems and load the driver there. This is absolutely not easy to do and just taking a look at the task list for such an endeavor gives you an idea of the complexity required. The results are awesome: you can find a matrix of kernels that are continuously tested for x86_64 and ARM as well! See the in-depth blog post to learn much more about this!\nFalco WASM Flaco is excited to introduce its latest addition: the WebAssembly target. This new target has been developed exclusively for the Falco Playground using Emscripten, where it brings essential core functionalities to the forefront. These functionalities include a rule compiler and the ability to reproduce events from capture files. It’s worth noting that certain features, such as kernel modules and Kubernetes support, have been intentionally omitted from this wasm target. This omission is due to the inherent limitations of running these features within a web browser environment. falco.wasm can be found as a github artifact in the latest workflow.\nFalco Playground Falco playground is simple web application where you can create, edit and validate falco rules. This is a quick solution for users wanting to easily check the accuracy of their custom rules. This application is completely client side and doesn’t make calls to any backend server. It leverages the power of WebAssembly to test your rules. You can try it live and find the code in the falco-playground repository!\nAdditional UX improvements With each release, Falco gets more quality-of-life improvements, such as:\nEnvironment variables resolution in configuration files A new outputs_queue configuration option to better fine tune Falco's output performance Deprecated features It's sad to see features go, but sometimes we need to remove something in order to focus on what matters for our adopters. This is what maintainers are proposing for deprecation in this release and removal in the next Falco version 0.37.0:\nThe optional rate-limiter mechanism, since it seems to be no longer used and it also can discard events including potentially critical alerts The --userspace option, since the corresponding feature and the associated projects in the Falco organization have not been maintained for years The falco-driver-loader bash script. The driver loading functionality is going to be implemented in falcoctl to improve Falco's driver loading capabilities and make it easier to maintain and contribute to. Try it out It’s time to try out the new release! Here are some pointers for getting started with Falco:\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-no-driver (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package What next? 🔮 The community is active on many topics and we hope to deliver great features and many stability fixes once again during the next release cycle!\nThe old falco-driver-loader script is showing its age and it's time to work on a more maintainable solution. falcoctl is a great candidate to host everything driver related, implement new features and make our lives easier when we need to install Falco drivers on a new machine. Lately we have expanded the syscall coverage that Falco can provide. We wish to improve these efforts across all drivers with even more 32 bit syscalls. Our rule framework is brand new and we forsee many improvements and active development work on it. The latest Falco versions brought many improvements to the plugin framework; we wish to use those to create a more scalable Kubernetes client plugin that will be able to withstand much heavier loads and will be easier to maintain. And many, many, more enhancements!\nStay tuned 🤗 Join us in our communication channels and in our weekly community calls! It’s always great to have new members in the community, and we’re looking forward to having your feedback and hearing your ideas.\nYou can find all the most up to date information at https://falco.org/community/.\nSee you for the next release!\nEnjoy,\nLuca, Andrea, Rohith\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.36.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-36-0/"},{"category":"blog","content":"There are a few foundational technologies that empower the Cloud Native ecosystem. Containers is one. And one of the basis for containerization is the Linux Kernel itself. With Falco, we are developing a runtime security tool that hooks directly in the kernel to collect information about the system and notifies about malicious behavior.\nWe have found the need to validate our drivers against various versions of the Linux kernel, to properly ensure that with each iteration of our drivers, supported kernels remained unaffected.\nTo elaborate, we lacked a means to guarantee that a new driver release could:\nSuccessfully compile on multiple kernel versions. Pass the eBPF verifier when executed on various kernel versions. Operate as expected, such as retrieving kernel events, across multiple kernel versions. To address this issue, we started a major intervention. Initially, a proposal was discussed and incorporated into the libs repository.\nSince this was a pretty novel area, there were no pre-existing tools available to tackle it. Consequently, we embarked on the development of a completely new framework.\nAllow us to introduce you to the kernel testing framework.\nComponents of a kernel testing framework Considering the inherent characteristics of the challenge, we need to set up a complete virtual machine for each distinct kernel version.\nThese tests should be executed automatically each time new code is integrated into our drivers, serving as a means to promptly identify any issue or flaw in the tested kernel versions.\nWith these objectives in mind, our approach should fulfill the following requirements:\nRapid and cost-effective VM creation: the process of creating these virtual machines should be efficient and budget-friendly. Effortless distribution of VM images: we should ensure easy sharing and deployment of the virtual machine images. Parallel execution of tests on multiple VMs: tests should run concurrently on each virtual machine to expedite the process. Reproducibility in local environments for debugging purposes: developers should be able to replicate the test environment locally to investigate and troubleshoot issues. Straightforward and user-friendly presentation of the test results: they should be presented in a simple and intuitive manner to immediately spot failures. Ignite a Firecracker microVM Weave Ignite is used to provision the firecracker microVMs. Weave Ignite is an open source tool designed for lightweight and fast virtual machine management. It enables users to effortlessly create and manage virtual machines (VMs) for various purposes, such as development, testing, and experimentation. One of the main reasons why we chose to use this tool was its capability to create firecracker microVMs from kernels and rootfs packed as OCI images. Currently, we are using a patched version located at a forked repository. These patches were essential to enable the booting of kernels that necessitated the use of an initrd (initial ramdisk).\nKernel \u0026amp; Rootfs OCI images Virtual machines consist of two essential layers: the kernel and the rootfs. These layers are packaged and distributed as OCI (Open Container Initiative) images. The kernel image encompasses the kernel that the virtual machine relies on, in contrast the rootfs image serves as the fundamental building block of a virtual machine, offering the essential filesystem necessary for booting the VM. Typically, these rootfs images incorporate a Linux distribution. For more info on how we build them please check the available images documentation.\nAnsible Playbooks Automation is accomplished through the utilization of Ansible. A collection of playbooks is responsible for:\nOrchestrating the provisioning of microVMs. Configuring the machines. Retrieving the code to be tested. Eliminating the microVMs once the testing process is completed. Presenting test results We wanted the test data to be publicly and easily accessible by anyone, thus we had to find a way to represent the test output.\nSince there are 3 possible ways of instrumenting the kernel, that are using a kernel module or one of the available eBPF probes, the playbooks perform up to 3 tests. Taking into account that the modern eBPF probe is built in the Falco libraries, only 2 drivers need to be compiled. We have 3 possible results for each of them:\nsuccess, when the test goes fine error, when the test fails skipped, when the test is not runnable for the kernel (for example, skipping modern eBPF tests where it is unsupported) The natural way of dealing with all of this was to develop a small tool that, given as input the output root folder, would generate a markdown matrix with the results.\nWhile scrutinizing the first version of the markdown matrix, we understood that it would have been even better if errors were also attached to the markdown, allowing for a more streamlined visualization of the results.\nThis is the format we settled with; it can be found at libs github pages:\nHow we use it We implemented a new Github action workflow in the libs repository that triggers on pushes to master, using an x86_64 and an aarch64 nodes with virtualization capabilities provided by the CNCF.\nThe workflow itself is very simple since it runs the testing framework on self-hosted nodes just like you would run it locally:\njobs: test-kernels: strategy: fail-fast: false matrix: architecture: [X64, ARM64] # We use a matrix to run our job on both supported arch # Since github actions do not support arm64 runners and they do not offer virtualization capabilities, we need to use self hosted nodes. runs-on: [ \u0026#34;self-hosted\u0026#34;, \u0026#34;linux\u0026#34;, \u0026#34;${{matrix.architecture}}\u0026#34; ] steps: # We clone the kernel-testing repo, generate vars.yaml (ie: input options for the kernel-testing run) # and run needed ansible playbooks one by one, directly on each node. - name: Checkout uses: actions/checkout@v3 with: repository: falcosecurity/kernel-testing ref: v0.2.3 - name: Generate vars yaml working-directory: ./ansible-playbooks run: | LIBS_V=${{ github.event.inputs.libsversion }} LIBS_VERSION=${LIBS_V:-${{ github.ref_name }}} cat \u0026amp;gt; vars.yml \u0026amp;lt;\u0026amp;lt;EOF run_id: \u0026amp;#34;id-${{ github.run_id }}\u0026amp;#34; output_dir: \u0026amp;#34;~/ansible_output_${{ github.run_id }}\u0026amp;#34; repos: libs: {name: \u0026amp;#34;falcosecurity-libs\u0026amp;#34;, repo: \u0026amp;#34;https://github.com/falcosecurity/libs.git\u0026amp;#34;, version: \u0026amp;#34;$LIBS_VERSION\u0026amp;#34;} EOF - name: Bootstrap VMs working-directory: ./ansible-playbooks run: | ansible-playbook bootstrap.yml --extra-vars \u0026amp;#34;@vars.yml\u0026amp;#34; - name: Common setup working-directory: ./ansible-playbooks run: | ansible-playbook common.yml --extra-vars \u0026amp;#34;@vars.yml\u0026amp;#34; - name: Prepare github repos working-directory: ./ansible-playbooks run: | ansible-playbook git-repos.yml --extra-vars \u0026amp;#34;@vars.yml\u0026amp;#34; - name: Run scap-open tests working-directory: ./ansible-playbooks run: | ansible-playbook scap-open.yml --extra-vars \u0026amp;#34;@vars.yml\u0026amp;#34; || : # Once test finished, we collect its output folder and upload it to the github workflow space - name: Tar output files run: | tar -cvf ansible_output.tar ~/ansible_output_${{ github.run_id }} - uses: actions/upload-artifact@v3 with: name: ansible_output_${{matrix.architecture}} path: ansible_output.tar # We then build the matrix and upload them too - name: Build matrix_gen working-directory: ./matrix_gen env: GOPATH: /root/go GOCACHE: /root/.cache/go-build run: | go build . - name: Generate new matrix working-directory: ./matrix_gen run: | ./matrix_gen --root-folder ~/ansible_output_${{ github.run_id }} --output-file matrix_${{matrix.architecture}}.md - uses: actions/upload-artifact@v3 with: name: matrix_${{matrix.architecture}} path: ./matrix_gen/matrix_${{matrix.architecture}}.md # Always run the cleanup playbook to avoid leaving garbage on the nodes - name: Cleanup if: always() working-directory: ./ansible-playbooks run: | ansible-playbook clean-up.yml --extra-vars \u0026amp;#34;@vars.yml\u0026amp;#34; || : In the Generate new matrix step, the kernel matrix gets generated and then uploaded.\nOnce this workflow runs successfully for both architectures, another workflow gets triggered,\nthat is responsible for generating and pushing updated Github pages.\nThe end result can be seen at https://falcosecurity.github.io/libs/matrix/.\nMoreover, the kernel-testing workflow gets also triggered on each driver's tag; then a supplementary workflow takes care of attaching matrixes to the release body;\nhere is an example: https://github.com/falcosecurity/libs/releases/tag/6.0.0%2Bdriver.\nPretty nice, uh?\nWhat's next for the framework There are quite a few gaps that still need to be addressed by our framework. First of all, the images being used by Ignite to spawn FireCracker VMs are still under a development Docker repository and need to be moved under Falcosecurity.\nMoreover, we need to implement a CI to automatically build and push those images.\nAs previously said, the kernel tests are currently running scap-open binary to check whether any event gets received. It is a small libscap C example that loads a driver and waits for events, nothing more.\nIt would be great to run drivers tests instead, to fully test the expected behavior of the drivers.\nFinally, an utopian idea: imagine if we were able to run kernel-crawler to fetch kernel images, and then automatically build new kernel testing matrix entries for newly discovered images.\nThis would mean that our kernel testing matrix coverage increases steadily week after week, giving users even more guarantees about the stability of the Falco drivers!\nHere is the libs tracking issue: https://github.com/falcosecurity/libs/issues/1224.\nWe would love to hear back from you! If you try out the framework and find any issues, please file them at https://github.com/falcosecurity/kernel-testing/issues. If you want to help us to improve, please join our Slack, and feel free to open a Pull Request!\n","summary":"","tags":["Falco\"","Falco Libs","Kmod","eBPF"],"title":"Introducing a framework for regression testing against Linux kernels","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-kernel-testing/"},{"category":"blog","content":"Not so long ago, we proudly released a new fantastic release of falcosidekick, it's time for its little brother, falcosidekick-ui to know the same, with the version v2.2.0.\nLet's take a tour to introduce the most important cool new features of this release.\nDisabling the authentication The previous version introduced a basic auth mechanism to protect access to the dashboard and API. Some complained it broke the access through their reverse proxy. You can now disable the authentication:\n-d boolean Disable authentication (environment \u0026#34;FALCOSIDEKICK_UI_DISABLEAUTH\u0026#34;) Dialog box to display the details of an event To have a better view of each event, you can now open a dialog box that displays all details but also the raw JSON of the event. You can even copy it into your clipboard with a simple click.\nTo display the dialog box, just click on the {...} at the end of the event row.\nExport A new Export button appeared, it allows you to export all the events found in json format. It takes in consideration the filters, of course.\nUnits for TTL For users with a lot of events, it can be useful to specify a TTL (time to live) for the keys in Redis (the storage backend). It can be done with -t argument for a while, and the value had to be in seconds, which is not convenient for long-term storage. You can now specify a unit (seconds, minutes, hours, Weeks, Months, year). If no unit is specified, it's considered as seconds to avoid breaking previous configs.\n-t string TTL for keys, the format is X\u0026lt;unit\u0026gt;, with unit (s, m, h, d, W, M, y)\u0026#34; (default \u0026#34;0\u0026#34;, environment \u0026#34;FALCOSIDEKICK_UI_TTL\u0026#34;) Redis password The access to the dashboard and the API can be protected by credentials, but the Redis wasn't. You can now specify a password for access to Redis, it will prevent your security scans from complaining ;-).\n-w string Redis password (default \u0026#34;\u0026#34;, environment \u0026#34;FALCOSIDEKICK_REDIS_PASSWORD\u0026#34;) Conclusion Thanks again to our amazing community, most of these features came from your ideas and we're still thrilled to see how much you find falcosidekick-ui useful.\nAs usual, if you have any feedback or need help, you can find us at any of the following locations.\nGet started in Falco.org Check out the Falcosidekick project on GitHub. Check out the Falcosidekick UI project on GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick-UI","Release"],"title":"Falcosidekick-UI 2.2.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-ui-2-2-0/"},{"category":"blog","content":"Introduction: In this article, we will delve into the details of eBPF (extended Berkeley Packet Filter) and explore its significance in tracing system calls. This particular blog will be in two parts; in the first blog, we will discuss eBPF, and in the subsequent section, we will delve into probes. eBPF is a powerful technology that allows for the dynamic and efficient tracing of events within the kernel space of an operating system. You have probably heard of the acronyms BPF and eBPF being used interchangeably. That's why we will aim to address both BPF and eBPF before discussing how and why Falco uses this technology.\nBPF (Berkeley Packet Filter) BPF is a technology used for network packet filtering and analysis. It is a powerful tool for implementing network security features, such as firewalls and intrusion detection systems. It can also be used to examine network traffic in real-time, detect suspicious patterns, and take appropriate actions to protect the network.\neBPF (Extended Berkeley Packet Filter) The Extended Berkeley Filter (eBPF) is an evolution of the original BPF technology. It extends the capabilities of BPF by providing a more powerful and flexible way to perform dynamic tracing, network analysis, and performance monitoring. It allows developers to write and load programs into the kernel which can be attached to various hooks and events in the system. These programs can provide real-time insights and control over system activities.\nWorking on an eBPF program The process of compiling and running an eBPF program involves several steps:\nThe eBPF program is converted into bytecode by using a compiler, ready to be loaded by a loader program.\nThe eBPF verifier checks the program for safety, correctness and adherence to specific rules and constraints. First of all, it performs a depth-first search on all possible execution paths to ensure that the program always proceeds to completion. Next, it performs a static analysis on the bytecode and ensures that the program doesn't violate memory access rules, and doesn't cause instability.\nOnce the eBPF program passes the verification process, it can be loaded into the kernel. The loader ensures that the program is securely loaded and attached to the desired hooks or targets in the system.\nAt runtime, the eBPF bytecode is further optimised through JIT (Just-in-time) compilation. This step converts the eBPF bytecode into machine code that can be executed by the CPU.\nKernel Modules Apart from eBPF, the other approach we previously discussed for process tracing in Linux is the use of kernel modules. Kernel modules allow developers to write custom code that can be loaded into the kernel to extend its functionality.\nBy leveraging kernel modules, it is possible to hook into various points of the kernel's process management code and capture detailed information about process execution. This includes events such as process creation, termination, and context switches.\nBy accessing the kernel's internal data structures and functions, the module can gather valuable insights such as process IDs, parent-child relationships, execution time, system calls, and more.\nSo why does Falco use eBPF? The integration of eBPF brings significant advantages to projects like Falco, empowering them to securely and efficiently monitor and analyze system calls in real-time. You might be wondering why eBPF is necessary when Falco already has real-time detection capabilities through its kprobe (kernel probe) that handles syscall events.\nOne compelling reason for incorporating eBPF support is to enable Falco to seamlessly operate in modern cloud native environments, where the traditional kernel probe may encounter limitations or face restrictions imposed by the control plane nodes.\nBy embracing eBPF, Falco ensures the continuity of its real-time detection capabilities in a secure manner, allowing for the prompt and accurate identification of security incidents, regardless of the underlying environment.\nLater in the article, we will delve into the various considerations surrounding the adoption of an eBPF probe for Falco, providing valuable insights for determining when it becomes advantageous to leverage this functionality.\neBPF programs vs kernel modules Safety and Isolation eBPF programs are subjected to a thorough verification process before they are loaded into the kernel. This step provides an extra layer of protection and helps prevent security vulnerabilities. In contrast, kernel modules have direct access to the kernel code, which can pose a threat to the system if not implemented correctly.\nPerformance eBPF programs are JIT compiled into machine code, which significantly improves the performance. JIT compilation optimizes the program for the specific CPU architecture, enabling efficient execution. Despite all these efforts, an eBPF instrumentation will always cause a greater overhead in the system than a kernel module one, the reason is that in the kernel module instrumentation there are no calls to the BPF subsystem.\nObservability and Debugging eBPF provides powerful tracing and observability capabilities. eBPF programs can be attached to various events, such as network packets, system calls, or kernel functions, allowing detailed visibility into the system behaviour. This makes eBPF a valuable tool for debugging, performance analysis, and security monitoring. Kernel modules typically require more invasive and complex mechanisms for achieving similar observability.\nAttaching eBPF programs to hooks and events There are various instrumentation points defined in the Linux kernel. An instrumentation is a specific point in a computer program where additional code, known as instrumentation code, is inserted to gather information about the program's execution. Instrumentation code can be injected at runtime using JIT compilation. Kernel probes, tracepoints, user-space probes, kretprobes are examples of instrumentation points.\nHere is an eBPF program that runs when the execve system call is made.\nIn the eBPF programming context, the macro SEC() from the bpf/bpf_helper.h header file plays a crucial role. It allows the programmer to specify the section in which a function or variable will be placed within the eBPF object file. This becomes essential when loading eBPF programs into the kernel using mechanisms like the bpf() system call.\nBy organizing functions and variables into named sections, the eBPF loader can efficiently locate and load the required code and data. Specifically, when dealing with tracepoint events, the SEC format follows the pattern SEC(\u0026quot;tp/\u0026lt;category\u0026gt;/\u0026lt;name\u0026gt;\u0026quot;), where \u0026lt;category\u0026gt; and \u0026lt;name\u0026gt; represent the respective tracepoint category and event name.\ntp/syscalls/sys_enter_execve refers to a tracepoint that records when a process spawns the execve system call.\nA list of all the available tracepoints is present in the /sys/kernel/debug/tracing/available_events file. The format for each line in the file is \u0026lt;category\u0026gt;:\u0026lt;name\u0026gt;. For example, syscalls:sys_enter_execve.\nBefore compiling the program, we need to do some basic configuration:\nLet's compile the program. The following command can be used to do this task:\nNow, we need to write a loader program that loads and attaches this program. This loader program is used to load and attach an eBPF program to the Linux kernel. It opens and loads the eBPF object file, checks for errors during the process, finds a specific eBPF program within the loaded object, and attaches it to the kernel. Once attached, the eBPF program will be executed when certain events occur. The program enters an infinite loop at the end, indicating that it will continue running until it is manually terminated.\nLet's compile and run this program\nTo get the logs generated by the function bpf_printk, we can read the file: /sys/kernel/tracing/trace_pipe\nManually reading messages from the tracepipe doesn't seem to be an efficient approach. It would be advantageous to establish a mechanism for the eBPF program to send messages to the loader program. One viable solution is to utilize ring buffers. Let’s review more details about ring buffers.\nRing buffers eBPF ring buffer, also known as bpf_ringbuf, is a mechanism provided by the Linux kernel for efficient communication between eBPF programs and user-space programs.\nIt allows the exchange of data and events between eBPF programs running in the kernel and user-space applications. It is a MPSC (Multi Producer Single Consumer) queue and can be safely shared across multiple CPUs simultaneously.\nThe eBPF ring buffer, being shared across all CPUs, offers a unified and efficient solution for managing memory utilisation, mitigating issues of overuse or under-allocation that commonly occur with perfbuf.\nLet's have a look at a few functions that we'll be using to write an eBPF program that sends data to userspace.\nbpf_ringbuf_reserve This function is used to reserve size bytes of space in a BPF ring buffer.\nbpf_probe_read_user_str This function is used to read a null terminated string from user-space memory into the destination dst. The dst parameter is a pointer to the destination buffer in the kernel space. unsafe_ptr is a pointer to the source string in the user-space.\nbpf_ringbuf_submit This function is used to submit data that had previously been reserved in a ringbuf.\nbpf_object__find_map_fd_by_name This function is used to find the file descriptor of a named map.\nbpf_program__attach_tracepoint This function is used to attach an eBPF program to a kernel tracepoint.\nring_buffer__new This function is used for creating and opening a new ringbuf manager.\nring_buf__consume Used to remove or consume data from a ring buffer.\nBTF (BPF Type Format) It provides a way to describe the types of data structures used by eBPF programs, allowing for improved type safety, debugging, and introspection.\nNow, let's write a program that sends data to userspace using ringbuf.\nHaving created the program, we can write a loader to load this eBPF program.\nThe infinite loop is necessary to ensure that the program continuously checks for new events in the ring buffer. Without the loop, the program would only consume events that were already in the buffer at the time of the initial ring_buffer__consume() call. By looping and calling ring_buffer__consume() repeatedly, the program can retrieve events as soon as they become available and process them in real-time. The sleep(1) call within the loop serves to reduce the CPU usage of the program by introducing a one-second delay between each call to ring_buffer__consume().\nGreat, we were able to recover the process name as well as the PID!\nConclusion In conclusion, this article has provided a comprehensive overview of eBPF (extended Berkeley Packet Filter) and its significance in tracing system calls. We have explored the evolution from BPF to eBPF, discussed why Falco uses this technology, and delved into the process of working with eBPF programs and ring buffers for efficient data communication between the kernel and user-space applications.\nAs we journeyed through the capabilities of eBPF in this first part, we uncovered its benefits in terms of safety, performance, and observability when compared to traditional kernel modules. eBPF empowers us to securely and efficiently monitor and analyze system calls in real-time, making it a valuable tool in modern cloud native environments.\nIn the upcoming second part of this blog series, we will further expand our exploration by delving into the realm of probes and additional advanced topics. We will dive deeper into how eBPF probes can be leveraged for enhanced system tracing, performance analysis, and security monitoring. Stay tuned for more insights and practical guidance on harnessing the power of eBPF.\nKeep an eye out for Part 2, where we'll continue our journey into the world of eBPF and system call tracing.\n","summary":"","tags":["eBPF","Falco","Syscalls"],"title":"Tracing System Calls Using eBPF - Part 1","url":"https://v0-43--falcosecurity.netlify.app/blog/tracing-syscalls-using-ebpf-part-1/"},{"category":"blog","content":"Along with many in the community, we were sad to hear the news of Kris Nóva's passing last week.\nNóva was a foundational contributor to Falco. She joined the Falco community when Falco was still a CNCF sandbox project. She made many contributions, including working on the input/output interfaces and starting the falcoctl project. She guided the community during the CNCF incubation process, and shepherded the contribution of the falcosecurity/libs to the CNCF. Over the years, she has been a powerful and enthusiastic ambassador, evangelizing runtime security, eBPF, and the Falco philosophy in countless venues around the world.\nEven after leaving Sysdig, Nóva remained involved in the project, acting as a strong and positive voice, both inside and outside the group of Falco maintainers. She crafted strategies, mediated community issues, and constructively gathered people around the project.\nWithout any doubt, we will miss Nóva's contributions. But even more than that, we will dearly miss a friend. Someone who genuinely cared for each of us, as family members. Someone who was there, always, without hesitation, when we needed help, technical or personal. Someone who inspired us by always following her passions and never (never!) compromising.\nWe will miss her reaching out, excited, to tell us about her latest technical idea. Or sending us pictures of her prior weekend’s mountaineering accomplishments.\nFalco is not going to be the same without her, but we are committed to continuing to observe the values she helped instill in the project.\nWe send our sympathies to her loved ones, and promise we won't forget her.\n","summary":"","tags":[],"title":"In memory of Kris Nóva","url":"https://v0-43--falcosecurity.netlify.app/blog/kris-nova/"},{"category":"blog","content":"Today, we'd like to share with the Falco community the latest contribution we (w/Emin Aktas) made to GitLab Container Registry.\nWe noticed that GitLab Container Registry didn't support Falcoctl OCI Artifact mediaTypes while we were pushing the Falco rules stored from GitHub container registry to GitLab container registry. We decided then to contribute to GitLab Container Registry by adding the support for Falcoctl OCI Artifact mediaTypes.\nError: PUT https://registry.gitlab.com/v2/x/falcosecurity/rules/k8saudit-rules/manifests/1: MANIFEST_INVALID: manifest invalid; unknown media type: application/vnd.cncf.falco.rulesfile.config.v1+json Error: PUT https://registry.gitlab.com/v2/x/falcosecurity/plugins/k8saudit/manifests/sha256:b29c97a6590486f8b3b83644677e11d2f68e201a7035699189653d7f571d7e13: MANIFEST_INVALID: manifest invalid; unknown media type: application/vnd.cncf.falco.plugin.config.v1+json You can learn more about our contribution here. Once the feature is released, planned for GitLab 16.3, it will allow you to pull and push Falcoctl OCI Artifacts from and to GitLab Container Registry.\nFalcoctl is one of the newest development efforts from the Falco community. It is a CLI tool that allows you to manage the complete lifecycle of your Falco rules and plugins by leveraging the power of OCI Artifacts.\nFor those who are not familiar with the OCI Artifacts concept, the OCI Artifacts specification is a way to extend the OCI Registry specification to support storing and retrieving arbitrary content, you can learn more about OCI Artifacts concept, here. OCI Artifacts are important because today's moden software requires storing more than just container images in OCI registries such as the following artifacts would be great use-case examples of that:\nHelm charts WebAssembly modules Falco rules and plugins. :) ...many other custom artifacts You can even create your own custom OCI Artifacts. A key thing of OCI registries is uniquely identifying the type. This is done by using a media type, which is a string that identifies the type of content stored in the registry. The media type is used to determine how to interpret the content when it is retrieved from the registry. To learn more about how you can write your own custom OCI Artifacts, you can check out the OCI Artifacts Authoring guide.\nDistributing software artifacts as OCI Artifacts served by OCI registries offers a standardized, secured, and efficient way to consume and reuse content within the container ecosystem, making it easier to integrate, distribute, and manage them across different environments and tools.\nHope you can enjoy the new feature once it's released. See you next time! :)\n","summary":"","tags":["Rules","Falco Plugins","Falcoctl","Configuration Management"],"title":"GitLab Container Registry now supports Falcoctl OCI Artifacts","url":"https://v0-43--falcosecurity.netlify.app/blog/gitlab-supports-falcoctl-ociartifacts/"},{"category":"blog","content":"It's summertime, it's hot, and many people are on vacation, but the Falco community is still there. Six months after the release of Falcosidekick's latest upgrade, version 2.28.0 becomes officially available.\nThe number of pulls of the official Falcosidekick image from Docker Hub has also just reached 15M, which we consider mind-blowing. It took it 3 years to reach the first 5M pulls and now it's needed less than six months to do it again. Awesome!\nOnce more, Falcosidekick expands Falco's integrability with a lot of new outputs. That and the introduction of many new features has been possible thanks to the hard work of the community. You can find a comprehensive list of these in the changelog.\nNew outputs With every new release, the number of integrations of Falcosidekick increases. We have reached the number of 58 available outputs already, and we hope the threshold of 60 will be left behind very soon.\nRedis Redis is a well-known in-memory database with many years of adoption on its path. It is now possible for Falcosidekick to use it as an output destination, thanks to the contributions of pandyamarut.\nTelegram Telegram, the instant messaging platform, is becoming more and more used by companies for notifications, and thanks to zufardhiyaulhaq, it can receive Falco alerts too.\nN8N Do you want to extend the possibilities or just avoid developing a script to react to Falco events? Here comes n8n.\nGrafana OnCall At the last KubeCon, we met with some of the Grafana maintainers. We discussed the integration of Falco using Falcosidekick within the OnCall project. It's done now.\nOpenObserve OpenObserve is a young but promising full stack observability platform.\nNew features Aside from new outputs, we introduced very important and useful new features. Let's do a recap of them.\nUse different methods for the Webhook output Since its implementation, the Webhook output has only used the HTTP method POST. Now, you can choose between the POST and PUT methods to send your data, extending the catalog of possible REST APIs to use it with.\nwebhook: method: \u0026#34;POST\u0026#34; # HTTP method: POST or PUT (default: POST) Replace the brackets in the payload Some Falco fields refer to lists and reflect that their keys contain brackets, like proc.args[0], proc.args[1], etc. Unfortunately, some outputs may refuse payloads with brackets in keys. For this reason, we introduced the possibility of replacing them with any other chosen character:\nbracketreplacer: \u0026#34;_\u0026#34; # if not empty, the brackets in keys of Output Fields are replaced Set custom headers for Loki, Elasticsearch and Grafana outputs If you want to protect your private instances of Loki, Grafana, or Elasticsearch you may need to specify custom headers. This new feature allows you to do so.\nelasticsearch: customHeaders: # Custom headers to add in POST. Useful for Authentication key: value Match the priority with the severity for the AlertManager output AlertManager is a pretty common software at companies also using Prometheus. Until now, the mapping between the Priority of Falco events and the Severity of AlertManager was already predefined. You can now define it depending on your needs thanks to Lowaiz.\nalertmanager: customseveritymap: \u0026#34;\u0026#34; # comma separated list of tuple composed of a \u0026#39;:\u0026#39; separated Falco priority and Alertmanager severity that is used to override the severity label associated to the priority level of falco event. Example: debug:value_1,critical:value2. Default mapping: emergency:critical,alert:critical,critical:critical,error:warning,warning:warning,notice:information,informational:information,debug:information. (default: \u0026#34;\u0026#34;) Set thresholds for the dropped events for the AlertManager output Another contribution from Lowaiz: You can now configure a set of thresholds to start dropping the events.\nalertmanager: # dropeventdefaultpriority: \u0026#34;\u0026#34; # default priority of dropped events, values are emergency|alert|critical|error|warning|notice|informational|debug (default: \u0026#34;critical\u0026#34;) dropeventthresholds: # comma separated list of priority re-evaluation thresholds of dropped events composed of a \u0026#39;:\u0026#39; separated integer threshold and string priority. Example: `10000:critical, 100:warning, 1:informational` (default: `\u0026#34;10000:critical, 1000:critical, 100:critical, 10:warning, 1:warning\u0026#34;`) Better integration with TimescaleDB We thank hileef for improving the integration with TimescaleDB.\nUser roleARN and externalID for the AWS outputs Under some situations, you may want Falcosidekick to assume a role, possibly from another account. You can do it with the new pair of settings rolearn and externalid:\naws: rolearn: \u0026#34;\u0026#34; # aws role to assume (optional if you use EC2 Instance Profile) externalid: \u0026#34;\u0026#34; # external id for the role to assume (optional if you use EC2 Instance Profile) Set the region for the PagerDuty output Falcosidekick allows you to select between one of the two different regions' PagerDuty offers now.\npagerduty: region: \u0026#34;us\u0026#34; # Pagerduty Region, can be \u0026#39;us\u0026#39; or \u0026#39;eu\u0026#39; (default: us) Allow TLS for the SMTP output It is now possible to communicate with an SMTP server using TLS.\nsmtp: tls: false # Use TLS connection (true/false). Default: true Set attributes to GCP PubSUb messages GCP PubSub accepts attributes in its messages. You can specify yours, thanks to annadorottya.\ngcp: customAttributes: # Custom attributes to add to the Pub/Sub messages key: value More options for TLS and mTLS These are the most relevant changes of this release. To improve security, Falcosidekick can now listen using HTTPS with TLS. You can also be more specific with the keys and certificates for the mTLS for the outputs.\nmutualtlsfilespath: \u0026#34;/etc/certs\u0026#34; # folder which will used to store client.crt, client.key and ca.crt files for mutual tls for outputs, will be deprecated in the future (default: \u0026#34;/etc/certs\u0026#34;) # certfile: \u0026#34;/etc/certs/client/client.crt\u0026#34; # client certification file keyfile: \u0026#34;/etc/certs/client/client.key\u0026#34; # client key cacertfile: \u0026#34;/etc/certs/client/ca.crt\u0026#34; # for server certification tlsserver: # certfile: \u0026#34;/etc/certs/server/server.crt\u0026#34; # server certification file keyfile: \u0026#34;/etc/certs/server/server.key\u0026#34; # server key The mutualtlsfilespath setting is kept for now for backward compatibility but it will be remove in future\nIn some edge cases, you may need some endpoints to listen in HTTP only. You can specifically define them together with the associated port:\ntlsserver: notlsport: 2810 # port to serve http server serving selected endpoints (default: 2810) notlspaths: # if not empty, a separate http server will be deployed for the specified endpoints - \u0026#34;/metrics\u0026#34; - \u0026#34;/healthz\u0026#34; Thanks to annadorottya for her impressive work on this functionality.\nAutocreate the topic for the Kafka output When Falcosidekick doesn't detect the topic, it can create it automatically. This feature is not enabled by default.\nkafka: topiccreation: false # auto create the topic if it doesn\u0026#39;t exist (default: false) Support multiple bootstrap servers and TLS for the Kafka output To get better resiliency, you can now specify several bootstrap servers and even communicate with them with TLS, thanks to ibice.\nkafka: tls: false # Use TLS for the connections (default: false) Fixes We're not going to go into detail about all the corrections made in this version - you can find the full list here. Thanks to everyone who reported issues and to those who have corrected them.\nThe most important have been:\nFix breaking brackets in AWS SNS messages. Fix setting name for the table of TimescaleDB output (thanks to alika). Fix the cardinality issue with Prometheus labels. Fix panic when asserting output fields that are nil. Fix URL generation for Spyderbat output (thanks to bc-sb). Fix nil values in Spyderbat output (thanks to spider-guy). Fix duplicated headers in SMTP output (thanks to apsega). Conclusion The respective Helm charts are also updated and allow you to test for yourself all these great new features. Just issue the helm repo update; helm upgrade --reuse-values -n falco command to do so.\nFalcosidekick is now mentioned in the official Falco docs. It's a shy beginning, but more details will come shortly.\nOnce again, thanks to all the adopters and contributors who helped and contributed to this project all these years. We would never have reached this success without you.\nGet started in Falco.org Check out the Falcosidekick project on GitHub. Check out the Falcosidekick UI project on GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Release"],"title":"Falcosidekick 2.28.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-2-28-0/"},{"category":"blog","content":"The NIST organization, a non-regulatory federal agency in the United States, plays a crucial role in establishing guidelines across various domains, including cybersecurity. In this article, we focus on NIST 800-171 compliance checks, which pertain to the management of Controlled Unclassified Information (CUI) in non-federal systems \u0026amp; organizations. NIST 800-171 sets forth guidelines \u0026amp; requirements specifically aimed at safeguarding CUI.\nIt is worth noting that NIST 800-171 closely aligns with the NIST 800-53 framework. While the latter framework outlines security controls applicable to federal agencies and their contractors, NIST 800-171 specifically addresses the management of CUI, ensuring its protection and confidentiality within non-federal systems and organizations.\nThe inception of NIST 800-171 can be traced back to Executive Order 13556, signed by President Obama in 2010, which aimed to enhance the protection of CUI within federal agencies. The goal was to establish a standardized policy for data sharing and transparency across all agencies.\nIn the wake of significant breaches in government systems, most notably the 2020 United States federal government data breach that involved the exploitation of U.S. supply chain firms such as Microsoft, SolarWinds, and VMware to gain unauthorized access to federal systems, has exemplified the importance of strong cybersecurity controls at the federal level.\nWhile delving into the extensive history of the NIST framework is beyond the scope of this article, we will focus on explaining the requirements of NIST 800-171 and explore how the open source tool Falco can be utilized to detect potential control failures in cloud-native systems.\nListing the Requirements The NIST 800-171 documentation provides a comprehensive list of 14 controls accompanied by their corresponding compliance requirements. For the purpose of this article, we will focus on how Falco can effectively address 3 of the 14 controls and their corresponding requirements to ensure compliance in-line with the NIST 800-171 documentation.\nAccess Controls: Who has access to data and whether or not they’re authorized. AC-2 : Account Management AC-6 : Least Privilege Audit \u0026amp; Accountability: Know who’s accessing CUI and who’s responsible for what. AU-9 : Protection of Audit Information AU-10 : Non-repudiation Configuration Management: Follow guidelines to maintain secure configurations. CM-5 : Access Restrictions for Change CM-7 : Least Functionality Awareness \u0026amp; Training: Your staff should be adequately trained on CUI handling. Identification \u0026amp; Authentication: Manage and audit all instances of CUI access. Incident Response: Data breach preparedness and response plan protecting CUI. Maintenance: Ensure ongoing security and change management to safeguard CUI. Media Protection: Secure handling of backups, external drives, and backup equipment. Physical Protection: Authorized personnel only in physical spaces where CUI lives. Personnel Security: Train your staff to identify and prevent insider threats. Risk Assessment: Conduct pen testing and formulate a CUI risk profile. Security Assessment: Verify that your security procedures are in place and working. System and Communications Protection: Secure your comms channels and systems. System and Information Integrity: Address new vulnerabilities and system downtime. Access Controls The first control family in NIST 800-171, Access Controls, emphasizes the importance of enforcing secure access to systems and data. Open source Intrusion Detection System (IDS) tools like Falco can play a significant role in monitoring and enhancing access controls.\nFalco can be used to monitor access enforcement by detecting unauthorized access attempts, unusual login patterns, or suspicious user activities. It can also aid in user identification and authentication, ensuring that only authorized users gain access to sensitive resources.\nNIST AC-2 - Account Management The NIST control AC-2 pertains to account management. It focuses on the establishment and management of user accounts; including the creation, modification, and termination of accounts, as well as the assignment of associated privileges.\nThe Falco rule System User Interactive detects any attempt to run interactive commands by a system user (i.e. non login user). By monitoring system user interactions, Falco can identify instances where system users, who typically do not engage in interactive sessions, attempt to execute commands interactively.\nThis rule helps enforce proper account management practices by flagging potentially unauthorized activities or misuse of system accounts. For example, if a non-login system user attempts to run interactive commands, it may indicate an unauthorized attempt to gain access or perform actions beyond their intended privileges.\n- rule: System user interactive desc: an attempt to run interactive commands by a system (i.e. non-login) user condition: spawned_process and system_users and interactive and not user_known_system_user_login output: \u0026#34;System user ran an interactive command (user=%user.name user_loginuid=%user.loginuid)\u0026#34; priority: INFO tags: [host, container, users, mitre_execution, T1059, NIST_800-53_AC-2] NIST AC-6 - Least Privilege Regarding Least Privilege, organizations are expected to employ the principle of least privilege where possible. This means allowing only authorized and expected users accesses which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.\nThere are several Falco rules that can support least privilege security observability and therefore proof of violations.\n- rule: Unexpected K8s NodePort Connection desc: Detect attempts to use K8s NodePorts from a container condition: (inbound_outbound) and fd.sport \u0026gt;= 30000 and fd.sport \u0026lt;= 32767 and container and not nodeport_containers output: Unexpected K8s NodePort Connection (command=%proc.cmdline pid=%proc.pid connection=%fd.name container_id=%container.id image=%container.image.repository) priority: NOTICE tags: [network, k8s, container, mitre_persistence, T1205.001, NIST_800-53_AC-6] As you can see in the above example, there is very little to configure since the port numbers are in a range between 30000 and 32767, and this is the expected range used by a NodePort service.\nA macro named inbound_outbound is defined to handle the types of events (accept, listen and connect) as well as the expected localhost IP’s, as stated below:\n- macro: inbound_outbound condition: \u0026gt; ((((evt.type in (accept,listen,connect) and evt.dir=\u0026lt;)) and (fd.typechar = 4 or fd.typechar = 6)) and (fd.ip != \u0026#34;0.0.0.0\u0026#34; and fd.net != \u0026#34;127.0.0.0/8\u0026#34;) and (evt.rawres \u0026gt;= 0 or evt.res = EINPROGRESS)) Here are a number of Falco rules that can be fine-tuned to your organization’s environment to achieve least privilege control observability, such as:\nUnexpected outbound connection destination Unexpected inbound connection source Unexpected UDP Traffic For each of these rules you’ll need to populate the associated list items with the allowed sources/destinations:\n- list: allowed_outbound_destination_domains items: [google.com, www.yahoo.com] Audit \u0026amp; Accountability The second NIST control family aims to establish mechanisms for recording and reviewing system activities to ensure accountability, detect security incidents, and support investigations. This control focuses on implementing robust audit capabilities, including the collection, protection, analysis, and retention of audit logs. By implementing this control, organizations can enhance their ability to track and monitor system events, detect suspicious activities or policy violations, and maintain an audit trail for forensic analysis and compliance purposes.\nNIST AU-9 - Protection of Audit Information Audit information pertains to all information needed to successfully audit system activity, such as audit records, audit log settings, audit reports, and personally identifiable information. Audit logging tools are those programs and devices used to conduct system audit and logging activities.\nYou can use Falco rules to maintain NIST compliance by detecting and alerting when there are modifications to your logging tools, such as the CloudTrail Logging Disabled rule below:\n- rule: CloudTrail Logging Disabled desc: The CloudTrail audit logging has been disabled, this could be potentially malicious. condition: ct.name=\u0026#34;StopLogging\u0026#34; and not ct.error exists output: The CloudTrail logging has been disabled. (requesting user=%ct.user, requesting IP=%ct.srcip, AWS region=%ct.region, resource name=%ct.request.name) priority: WARNING tags: [cloud, aws, aws_cloudtrail, NIST_800-53_AU-9] source: aws_cloudtrail NIST AU-10 - Non-repudiation In the context of NIST compliance, non-repudiation ensures that a party cannot deny their involvement in a particular action or transaction.\nThe Falco rule Clear Log Activities aligns with the requirement of non-repudiation by discouraging or preventing the deletion or modification of log activities. Logs are essential for capturing and preserving records of events and actions within a system or application. They serve as a crucial source of evidence for auditing, forensic investigations, and compliance purposes.\n- rule: Clear Log Activities desc: Detect clearing of critical log files condition: \u0026gt; open_write and access_log_files and evt.arg.flags contains \u0026#34;O_TRUNC\u0026#34; and not trusted_logging_images and not allowed_clear_log_files output: \u0026gt; Log files were tampered (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline) priority: WARNING tags: [host, container, filesystem, mitre_defense_evasion, NIST_800-53_AU-10] The above Falco rule monitors for activities or commands that attempt to clear or tamper with log files. By detecting and alerting on such actions, it helps ensure the integrity and non-repudiation of log data. This rule can help organizations comply with NIST guidelines by preserving the availability and authenticity of logs, making it difficult for malicious actors or legitimate users to manipulate or delete log entries of their activity/actions.\nConfiguration Management The third NIST control family encompasses a set of controls designed to establish and maintain an organization's baseline configuration for its information systems. These controls focus on effectively managing and controlling changes to hardware, software, and firmware configurations. The purpose of the Configuration management controls ensure that systems are securely configured, minimize vulnerabilities, and maintain the integrity and stability of the organization's IT environment.\nBy implementing robust configuration management practices, organizations can effectively track and manage configuration changes, reduce the risk of unauthorized modifications, and establish a foundation for secure and reliable operations. These controls play a crucial role in maintaining the overall security posture of an organization's information systems.\nNIST CM-5: Access Restrictions for Change The CM-5 requirement focuses on establishing and maintaining access restrictions for changes made to a system. The goal is to ensure that access to system components and resources is appropriately defined, documented, approved, and enforced throughout the change process. This control helps mitigate the risk of unauthorized or malicious changes that could compromise the system's security or integrity.\nThe below K8s Audit Log Falco rule effectively detects unauthorized service account creations in the kube-system and/or kube-public namespaces, aligning with NIST control CM-5 objectives. By monitoring these creations, it ensures that access controls are properly defined, documented, and enforced in line with security policies. This enhances compliance, provides visibility into potential deviations, enables prompt remediation, and upholds system integrity and security.\n- rule: Service Account Created in Kube Namespace desc: Detect any attempt to create a service account in the kube-system or kube-public namespaces condition: kevt and serviceaccount and kcreate and ka.target.namespace in (kube-system, kube-public) and response_successful and not trusted_sa output: Service account created in kube namespace (user=%ka.user.name serviceaccount=%ka.target.name resource=%ka.target.resource ns=%ka.target.namespace) priority: WARNING source: k8s_audit tags: [k8s, NIST_800-53_CM-5] NIST CM-7: Least Functionality The NIST control CM-7 emphasizes the implementation and maintenance of the least functionality principle, aiming to limit the capabilities of information systems to essential functions. Falco's capability to detect unauthorized inbound and outbound connections is one way to support the enforcement of the least privilege control.\n- rule: Outbound or Inbound Traffic not to Authorized Server Process and Port desc: Detects traffic that is not to the authorized server process and port. condition: \u0026gt; inbound_outbound and container and container.image.repository in (allowed_image) and not proc.name in (authorized_server_binary) and not fd.sport in (authorized_server_port) enabled: false output: \u0026gt; Network connection outside authorized port and binary (command=%proc.cmdline pid=%proc.pid connection=%fd.name user=%user.name user_loginuid=%user.loginuid container_id=%container.id image=%container.image.repository) priority: WARNING tags: [container, network, mitre_discovery, TA0011, NIST_800-53_CM-7] Conclusion In conclusion, we have explored three essential NIST control families: Access Controls, Audit \u0026amp; Accountability, and Configuration Management. These control families address crucial aspects of information security, such as ensuring secure access to systems and data, establishing mechanisms for recording and reviewing system activities, and effectively managing and controlling configuration changes. By covering these control families, we have highlighted the significance of implementing strong security practices to protect sensitive information and maintain compliance with regulatory frameworks like NIST.\nMoreover, it is crucial to detect misconfigured controls and insecure behaviors in real-time. Timely detection allows incident response teams to take immediate corrective actions, preventing potential security incidents and ensuring compliance with regulatory frameworks like NIST. Falco has open source rules that you can quickly and easily implement/use to comply with the nist framework. Falco’s real-time detections enable organizations to proactively identify and respond to security risks, minimize the impact of incidents, and safeguard sensitive data.\nBy maintaining compliance with NIST and other regulatory requirements, organizations can enhance their security posture, build trust with stakeholders, and mitigate the potential legal, financial, and reputational consequences of non-compliance. Prioritizing real-time detection and swift incident response is essential in maintaining a robust security posture and upholding regulatory compliance.\nIf you would like to know how Falco meets additional regulatory frameworks, check out the Falco blog on enforcing PCI/DSS controls in cloud-native systems - https://falco.org/blog/falco-pci-controls/.\nAs usual, if you have any feedback or need help, you can find us at any of the following locations.\nGet started in Falco.org Check out the Falco project on GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":null,"title":"Validating NIST Requirements with Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-nist-controls/"},{"category":"blog","content":"This week I worked on creating parsers for the syscalls that I added previously. I learnt how metadata is extracted from the syscalls to provied user with more context on the triggred syscall. We also compiled Falco's main repository from which the web application will be built on. As always, thanks to my mentor Jason Dellaluce for assisting me!\nWasm Target For Falco 🦅 Now that Libs has wasm support, it's time for Falco to get it's new target as well.\nSimilar approch to libs was followed here as well. We first modified cmakelist to add the wasm target and added the preprossesor checks for emscripten. Finally we added CI to build and test wasm target for flaco.\nMore information about this, here.\nA quick run of falco --help command through node.js 🤩\nroot@rohithraju:~/code/falco/build_emcc# node ./userspace/falco/falco.js --help Falco - Cloud Native Runtime Security Usage: falco [OPTION...] -h, --help Print this page -c \u0026lt;path\u0026gt; Configuration file. If not specified uses /etc/falco/falco.yaml. -A Monitor all events supported by Falco defined in rules and configs. Please use the -i option to list the events ignored by default without -A. This option affects live captures only. Setting -A can impact performance. -b, --print-base64 Print data buffers in base64. This is useful for encoding binary data that needs to be used over media designed to consume this format. --cri \u0026lt;path\u0026gt; Path to CRI socket for container metadata. Use the specified socket to fetch data from a CRI-compatible runtime. If not specified, uses the libs default. This option can be passed multiple times to specify socket to be tried until a successful one is found. -d, --daemon Run as a daemon. --disable-cri-async Disable asynchronous CRI metadata fetching. This is useful to let the input event wait for the container metadata fetch to finish before moving forward. Async fetching, in some environments leads to empty fields for container metadata when the fetch is not fast enough to be completed asynchronously. This can have a performance penalty on your environment depending on the number of containers and the frequency at which they are created/started/stopped. --disable-source \u0026lt;event_source\u0026gt; Disable a specific event source. By default, all loaded sources get enabled. Available sources are 'syscall' and all sources defined by loaded plugins supporting the event sourcing capability. This option can be passed multiple times. This has no offect when reading events from a trace file. Can not disable all event sources. Can not be mixed with --enable-source. --dry-run Run Falco without proceesing events. Can be useful for checking that the configuration and rules do not have any errors. -D \u0026lt;substring\u0026gt; Disable any rules with names having the substring \u0026lt;substring\u0026gt;. This option can be passed multiple times. Can not be mixed with -t. -e \u0026lt;events_file\u0026gt; Read the events from a trace file \u0026lt;events_file\u0026gt; in .scap format instead of tapping into live. --enable-source \u0026lt;event_source\u0026gt; Enable a specific event source. If used, all loaded sources get disabled by default and only the ones passed with this option get enabled. Available sources are 'syscall' and all sources defined by loaded plugins supporting the event sourcing capability. This option can be passed multiple times. This has no offect when reading events from a trace file. Can not be mixed with --disable-source. -i Print all high volume syscalls that are ignored by default for performance reasons (i.e. without the -A flag) and exit. -L Show the name and description of all rules and exit. If json_output is set to true, it prints details about all rules, macros and lists in JSON format -l \u0026lt;rule\u0026gt; Show the name and description of the rule with name \u0026lt;rule\u0026gt; and exit. If json_output is set to true, it prints details about the rule in JSON format --list [=\u0026lt;source\u0026gt;(=)] List all defined fields. If \u0026lt;source\u0026gt; is provided, only list those fields for the source \u0026lt;source\u0026gt;. Current values for \u0026lt;source\u0026gt; are \u0026quot;syscall\u0026quot; or any source from a configured plugin with event sourcing capability. --list-syscall-events List all defined system call events. --list-plugins Print info on all loaded plugins and exit. -M \u0026lt;num_seconds\u0026gt; Stop collecting after \u0026lt;num_seconds\u0026gt; reached. (default: 0) --markdown When used with --list/--list-syscall-events, print the content in Markdown format -N When used with --list, only print field names. --nodriver Capture for system events without drivers. If a loaded plugin has event sourcing capability and can produce system events, it will be used to for event collection. -o, --option \u0026lt;opt\u0026gt;=\u0026lt;val\u0026gt; Set the value of option \u0026lt;opt\u0026gt; to \u0026lt;val\u0026gt;. Overrides values in configuration file. \u0026lt;opt\u0026gt; can be identified using its location in configuration file using dot notation. Elements which are entries of lists can be accessed via square brackets []. E.g. base.id = val base.subvalue.subvalue2 = val base.list[1]=val --plugin-info \u0026lt;plugin_name\u0026gt; Print info for a single plugin and exit. This includes all descriptivo info like name and author, along with the schema format for the init configuration and a list of suggested open parameters. \u0026lt;plugin_name\u0026gt; can be the name of the plugin or its configured library_path. -p, --print \u0026lt;output_format\u0026gt; Add additional information to each falco notification's output. With -pc or -pcontainer will use a container-friendly format. With -pk or -pkubernetes will use a kubernetes-friendly format. Additionally, specifying -pc/-pk will change the interpretation of %container.info in rule output fields. -P, --pidfile \u0026lt;pid_file\u0026gt; When run as a daemon, write pid to specified file (default: /var/run/falco.pid) -r \u0026lt;rules_file\u0026gt; Rules file/directory (defaults to value set in configuration file, or /etc/falco_rules.yaml). This option can be passed multiple times to read from multiple files/directories. -s \u0026lt;stats_file\u0026gt; If specified, append statistics related to Falco's reading/processing of events to this file (only useful in live mode). --stats-interval \u0026lt;msec\u0026gt; When using -s \u0026lt;stats_file\u0026gt;, write statistics every \u0026lt;msec\u0026gt; ms. This uses signals, and has a minimum threshold of 100 ms. Defaults to 5000 (5 seconds). -S, --snaplen \u0026lt;len\u0026gt; Capture the first \u0026lt;len\u0026gt; bytes of each I/O buffer. By default, the first 80 bytes are captured. Use this option with caution, it can have a strong performance impact. (default: 0) --support Print support information including version, rules files used, etc. and exit. -T \u0026lt;tag\u0026gt; Disable any rules with a tag=\u0026lt;tag\u0026gt;. This option can be passed multiple times. Can not be mized with -t -t \u0026lt;tag\u0026gt; Only run those rules with a tag=\u0026lt;tag\u0026gt;. This option can be passed multiple times. Can not be mixed with -T/-D. -U, --unbuffered Turn off output buffering to configured outputs. This causes every single line emitted by falco to be flushed which generates higher CPU usage but is useful when piping those outputs into another process or into a script. -u, --userspace Parse events from userspace. To be used in conjunction with the ptrace(2) based driver (pdig) -V, --validate \u0026lt;rules_file\u0026gt; Read the contents of the specified rules(s) file and exit. This option can be passed multiple times to validate multiple files. -v Verbose output. --version Print version number. --page-size Print the system page size (may help you to choose the right syscall ring-buffer size). Conclusions\nOverall, I had so much fun building parsers for memfd_syscall and diving into the Falco's main repository. Going foward, I'll be working on front-end side of things which is very exciting. I'll have to come up with UI/UX designs which takes be back to the days I started my web developemt journey. I'm super ready to flex my creative muscles 😁.\n","summary":"","tags":["Gsoc","Week 3","Week 4"],"title":"Gsoc Week-3 and Week-4 updates","url":"https://v0-43--falcosecurity.netlify.app/blog/gsoc-2023-3rd-4th-week/"},{"category":"blog","content":"Introduction: The landscape of cybersecurity attacks has witnessed a notable rise in sophistication and complexity over the last decade, posing significant challenges to organizations in their efforts to identify and counter such threats effectively. It was within this context that the MITRE ATT\u0026amp;CK® Framework emerged as a valuable resource for security practitioners. In this blog, we will explore the benefits of using ATT\u0026amp;CK as a baseline to comprehensively understand threats, and Falco to detect and respond to these threats.\nThe ATT\u0026amp;CK Framework serves as an extensive repository of documented tactics, techniques, and procedures (TTPs) commonly employed by cyber adversaries. By gaining a comprehensive understanding of these TTPs, organizations can enhance their defensive capabilities and fortify their cybersecurity posture.\nFalco is a valuable open source tool that provides runtime security for containers, virtual machines, and standalone Linux hosts. Organizations use Falco to monitor, detect, identify, and respond to suspicious activity. Falco detects suspicious activities and alerts security teams in real-time based on static rules provided in the rules file.\nWhether you are a security analyst, a DevOps engineer, or an avid container enthusiast, this blog offers invaluable insights on utilizing MITRE ATT\u0026amp;CK-focused Falco rules to bolster your environment against advanced adversarial attacks.\nStep 1: Gather Necessary Details Consider the attacker’s perspective To create a rule that identifies a specific ATT\u0026amp;CK technique, you need to get inside the mind of the attacker. Imagine watching an attacker and thinking about how they might try to harm or take advantage of a victim’s environment. There are an endless number of things to consider, such as: changes to important files or folders; collection of user and network information; and the creation and upload of malicious scripts. Conducting an in-depth assessment of MITRE’s ATT\u0026amp;CK TTPs will provide you with enough information to understand an attacker’s perspective.\nKnow where to look In order to detect malicious activities using static rules, Falco relies heavily on system events (syscalls) generated within the user’s environment. To effectively observe these system behaviors, we must carefully consider the relevant system calls that occur during an attack. If network activity is involved, we must pay attention to the corresponding network traffic and alert on known malicious IP addresses. Additionally, we need to monitor the events that occur for files and directories during an attack. Armed with this knowledge, we can proceed to write rules that detect malicious activities as they unfold, ultimately triggering relevant events for further analysis and response.\nBring in Falco Falco uses a rule-based system to monitor application and container behavior in real-time. With predefined rules, Falco detects security threats like privilege escalation, file system manipulation, abnormal process execution, and many more. It continuously compares system activities against these rules, and either generates alerts or takes action when a match occurs. Since Falco is open source, its flexibility allows customization of rules to fit an organization’s specific security requirements. By integrating with container orchestration platforms, Falco collects data from various sources and applies the rules in real-time, enabling proactive threat detection and prevention for cloud-native applications.\nIt is important to note that Falco will not identify a type of attack or malware. Rather, its strength lies in efficiently detecting common malicious system behaviors. Falco acts as a notifier, bringing your attention to specific system activities that have occurred. Once alerted, it becomes your responsibility to investigate the activity and take the appropriate steps to mitigate and prevent further malicious activities.\nStep 2: Write the Falco Rule Rule writing is an iterative process that typically begins with crafting a basic rule, as best you can, and gradually refining its conditions to be more specific. It entails continually incorporating exceptions into the rule to prevent false positives, ensuring that events are not erroneously flagged as malicious. This process evolves over time as we identify activities related to an attack and incorporate them into the rule. Exceptions are crucial as they allow for the inclusion of benign activities that may be associated with malicious behavior. Avoiding false positives is vital, as it reduces noise by ensuring a rule does not incorrectly flag benign system changes or events as malicious activities.\nIdentify the MITRE technique Building upon our theoretical understanding of rule creation, we will now focus on the specific MITRE ATT\u0026amp;CK technique of Inhibit System Service and develop a Falco rule that can effectively identify this technique.\nThis technique is related to the recovery service of a system. Every system provides recovery services which are used in case of system failure. To make the system inaccessible an adversary may damage the system in such a way that the system becomes inaccessible to the user.\nHowever, operating systems, including Linux, provide built-in mechanisms to assist administrators in recovering from such situations. These mechanisms include features like backup catalogs, volume shadow copies, and automatic repair functionalities. These tools help administrators restore the system to a functional state by reverting to previous configurations or repairing damaged components.\nTo impede system recovery efforts, attackers may specifically target and disable these built-in mechanisms. They can employ various native Linux utilities to accomplish this task. For instance, they might use commands like \u0026quot;rm\u0026quot; and \u0026quot;systemctl\u0026quot; to delete important system files, or employ tools like \u0026quot;dd\u0026quot; to overwrite the hard drive with random data. By doing so, they hinder the ability of system administrators to leverage these recovery mechanisms effectively.\nUnderstand the technical details The following points provide an overview of the recovery features present in operating systems and the adversarial strategies employed to compromise them:\nRecovery feature for creating archives of data. These recovery features are given to store data on our system in the compressed form so that it can be used when it's needed by uncompressing it. Following are the tools which help us achieve this activity.\ntar: create a backup of the /home directory: tar -czvf home_backup.tar.gz /home rsync: synchronize files and directories: rsync -av /src /dest dd: create a disk image backup: dd if=/dev/sda of=/mnt/backup.img Adversary actions to make the data inaccessible to users. Now, an adversary may try to completely remove these archives by making all the data inaccessible. Delete backup files: rm /path/to/backupfile.tar.gz Overwrite backup data: dd if=/dev/zero of=/path/to/backupfile.img Recovery feature for creating snapshots of file systems. Creating snapshots of a filesystem is a common practice in data management and backup strategies. Snapshots are essentially point-in-time copies or representations of a filesystem, capturing its state at a specific moment. Following are some snapshot creation techniques.\nBtrfs: create a snapshot of the / filesystem: btrfs subvolume snapshot / /snapshot ZFS: create a snapshot of a dataset: zfs snapshot pool/dataset@snapshot Adversary actions to make file system broken: To remove the backup of filesystem an adversary might do following activities. In which it contains deleting the snapshots , modifying the snapshots to make it unusable. Delete snapshots: btrfs subvolume delete /path/to/snapshot Modify snapshots: vi /path/to/snapshot Boot Loader settings for banning of disabling recovery features The ability to ban or disable recovery features. The reason such settings exist is to provide system administrators or advanced users with the ability to control and secure the boot process according to their specific requirements.\nGRUB: modify the /etc/default/grub file to disable recovery mode GRUB_DISABLE_RECOVERY=true Adversary actions to try disabling all recovery features by modifying GRUB menu. An adversary may try to edit the grub configuration such that it disables the banning of certain recovery features. Modify GRUB configuration: vi /etc/default/grub Systemd services for system recovery In a Linux system, systemd is a widely used init system and service manager that plays a crucial role in managing the overall system and its services. It includes various features and components to ensure system recovery and maintain system availability. Here are the few recovery services present in the linux operating system.\nEnter rescue mode: add systemd.unit=rescue.target to the end of the linux line in the GRUB configuration file Switch to a different root filesystem: use the systemd-nspawn command Also, there are other important services like: recovery-mode.service emergency.service rescue.service apport.serviceAA Adversaries will try to disable the above system recovery services. Considering all these technical aspects and system changes that occur in a system when an adversary tries to inhibit system recovery, we can write a falco rule to identify these system events.\nFollow Falco guidelines The official Falco documentation provides all the rule fields, priorities, event, filenames, directory names, and covered syscalls that can be used in falco.\nDecide on a Rule Name: We need to first decide name of our rule, since we wrote a rule specific to an ATT\u0026amp;CK technique, let’s keep it similar: rule: Disable recovery features. Write a description: Define what is the purpose and intention for the rule that you intend to trigger. In our case, this can point to the definition of the ATT\u0026amp;CK technique we are capturing. desc: Detects disabling system recovery features by deleting or disabling services and commands. Define a Conditional Set: To trigger an event, we need to define conditions that encompass various system activities such as relevant system calls, file or directory modifications, involved commands, spawned process names, and connections to prohibited IP addresses. These technical details should come from the attack analysis done prior to rule writing. It is essential to adhere to the specified Falco format while crafting these conditions. Additionally, we must include exceptions to prevent false positives. Now, let us proceed to outline some fundamental conditions that will activate the desired event. - condition: \u0026gt; (spawned_process and proc.name = \u0026quot;rm\u0026quot; and proc.args contains \u0026quot;-rf\u0026quot;) or (spawned_process and proc.name = \u0026quot;chattr\u0026quot; and proc.args contains \u0026quot;+i\u0026quot;) or (spawned_process and proc.name = \u0026quot;mkfs.ext4\u0026quot; and proc.args contains \u0026quot;-E nodiscard\u0026quot;) or (spawned_process and proc.name = \u0026quot;mount\u0026quot; and proc.args contains \u0026quot;remount,ro\u0026quot;) or (spawned_process and proc.name = \u0026quot;systemctl\u0026quot; and proc.args contains \u0026quot;disable systemd-backlight@.service\u0026quot;) or (spawned_process and proc.name = \u0026quot;systemctl\u0026quot; and proc.args contains \u0026quot;disable apport.service\u0026quot;) or (spawned_process and proc.name = \u0026quot;systemctl\u0026quot; and proc.args contains \u0026quot;disable rescue.service\u0026quot;) or (spawned_process and proc.name = \u0026quot;systemctl\u0026quot; and proc.args contains \u0026quot;disable emergency.service\u0026quot;) or (spawned_process and proc.name = \u0026quot;systemctl\u0026quot; and proc.args contains \u0026quot;disable recovery-mode.service\u0026quot;)\nIn order to accommodate system administrators with the appropriate privileges to perform different tasks, such as the root user, we can introduce an exception in our conditions (e.g., user.name != \u0026quot;root\u0026quot;).\nLikewise, we can incorporate exceptions for specific processes that engage in these activities for legitimate reasons. These exceptions help fine-tune our conditions and reduce the occurrence of false positives. 4. Create an enabled field: This way you can optionally disable the rule as per your requirements. If this field is not set, the rule is automatically enabled by default. - enabled: true/false 5. Write an output field: This is the text that Falco sends you when alerting on a suspicious activity. Here we can use all fields that can be used in rule conditions to give output in a more descriptive way like process name, username, container name or id etc. - output: \u0026quot;Disabling recovery features so that system becomes non recoverable in case of failure.\u0026quot; 6. Specify a priority: The Falco team explains the concept of priorities within rules on their official documentation. It is important to clarify that the event is not triggered based on its assigned priority.\nRather, the event is triggered by specifying the priority level of a rule, which indicates the urgency in addressing it. Considering the paramount importance of this rule, we will assign it the highest priority level, known as CRITICAL: - priority: CRITICAL 7. Add Appropriate Tagging: In the final step, we will include tags for the rule. Tags serve as metadata providing additional information about the rules, although they are not mandatory fields. - tags:[mitre_impact, inhibit_system_recovery, T1490] When we bring all these elements together, our rule takes the following form: The team at CloudDefense.AI developed a Python Script that simulates an attack scenario by emulating system changes. 'Link To The Script'. To observe the corresponding output in the falco logs, you can try incorporating this rule into your falco_rules.local.yaml file and running the script.\nIt's important to note that certain system calls are not instantiated by default in alco, so you will need to execute Falco with all syscalls enabled. This can be achieved by running falco -A.\nConclusion To wrap up, we have delved into the pivotal role of Falco rules in securing our environments against ATT\u0026amp;CK-aligned attacks. By leveraging the synergies between the MITRE ATT\u0026amp;CK Framework and Falco's capabilities, we can greatly enhance our ability to detect and respond to potential threats.\nThroughout this blog, we have learned how to closely examine a MITRE ATT\u0026amp;CK technique and write a corresponding Falco rule to aid us and other Falco users in identifying suspicious activities. Equipped with this knowledge, we can better recognize and mitigate potential security threats.\nHowever, it is crucial to reiterate that this is an ongoing process and not a one-time solution. We have emphasized the significance of continuously refining our Falco rules to minimize false alarms and improve accuracy. By remaining vigilant and staying abreast of the latest attack vectors, we can proactively stay ahead of the curve and effectively protect our environments.\nUltimately, this blog has provided invaluable insights for security professionals and DevOps teams striving to bolster their defenses. By embracing the MITRE ATT\u0026amp;CK Framework and implementing targeted Falco rules, we can actively detect and respond to threats as they emerge, ensuring a robust shield against attackers.\n","summary":"","tags":["Falco","Falco Rules","MITRE ATT\u0026CK"],"title":"Crafting Falco Rules With MITRE ATT\u0026CK","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-mitre-attack/"},{"category":"blog","content":"Alright, it's week 2 and I've got some updates. This week I learnt the different nuances and difficulties that comes while trying to compile a project for a new target. In my case it was WebAssemebly.\nParts of Falco, which will be used for the web application is completely written in C and C++. So, we'll be using the emscripten toolchain to compile the C/C++ code into wasm.\nCompiling Falco to Wasm 😱 So, Falco's core logic is inside the libs repository.\nWe need to filter out libraries that won't be used and can't be compiled to wasm i.e kubernetes, grpc etc. There were a lot of modifications done, most of which are pre-processor checks for emscripten. Emscripten provies tools like emcmake and emmake to work with projects that are integrated using cmake build system. After that we wrote a github workflow that can sucessfully compile libs to wasm. It looks something like this.\nbuild-libs-emscripten: name: build-libs-emscripten runs-on: ubuntu-latest steps: - name: Install deps run: | sudo apt update sudo apt install -y --no-install-recommends ca-certificates cmake build-essential clang-14 llvm-14 git pkg-config autoconf automake libtool libelf-dev libcap-dev linux-headers-$(uname -r) emscripten - name: Checkout Libs uses: actions/checkout@v3 with: fetch-depth: 0 - name: Git safe directory run: | git config --global --add safe.directory $GITHUB_WORKSPACE - name: Build and test run: | mkdir -p build cd build \u0026amp;\u0026amp; emcmake cmake -DUSE_BUNDLED_DEPS=True ../ KERNELDIR=/lib/modules/$(ls /lib/modules)/build emmake make run-unit-tests -j4 You can find more information about the PR here.\nTesting the shiny new Wasm build 😎 During the final steps of compilation, the c++ exceutable will be converted to a .js file with a .wasm file linked to it. I loaded the wasm module with the help of a fancy react hook provied by my mentor, Jason and to my suprise! it worked without any additional configurations.\nThe above image contains the help funtion of a CLI interface. This is a simple std::cout\u0026lt;\u0026lt; statement that logs the entire string into the console.\nConclusions Overall, This week was super productive and informative for me. For the next week, I'm looking into adding parsers for the syscalls that I added previous week. Also we'll be supporting wasm build for Falco's main repository, which looks very exciting!\n","summary":"","tags":["Gsoc","week2","Mentorship"],"title":"GSoC Week 2 updates","url":"https://v0-43--falcosecurity.netlify.app/blog/gsoc-2023-2nd-week/"},{"category":"blog","content":"As organizations increasingly adopt cloud-native systems for sensitive data and operations, ensuring compliance with industry standards like the Payment Card Industry Data Security Standard (PCI DSS) becomes imperative. This standard is specific to those organizations that deal with cardholder data, such as payment processors, financial services providers, and ecommerce companies. Some organizations also use it as a type of high bar to elevate their security posture. Lawrence E Hecht of TheNewStack aptly discusses the distinctive monitoring and compliance enforcement challenges brought about by cloud-native environments in this article.\nIn this blog post, we will explore why Falco is a crucial component in detecting and enforcing PCI DSS compliance in cloud-native systems. We will delve into the key features and capabilities of Falco that make it an invaluable tool for monitoring, alerting, and maintaining the security and integrity of payment card data in the ever-evolving landscape of cloud-native technologies.\nListing the Requirements Here is a list of the 12 main requirements, also known as control objectives, of PCI/DSS. In this article we will discuss how Falco can be used to address 3 unique sub-controls objectives.\nInstall and maintain a firewall configuration to protect cardholder data Do not use vendor-supplied defaults for system passwords and other security parameters Protect stored cardholder data Encrypt transmission of cardholder data across open, public networks. Use and regularly update anti-virus software or programs Develop and maintain secure systems and applications Restrict access to cardholder data by business need-to-know Assign a unique ID to each person with computer access Restrict physical access to cardholder data Track and monitor all access to network resources and cardholder data Regularly test security systems and processes Maintain a policy that addresses information security for all personnel PCI Control #6 Develop and maintain secure systems \u0026amp; applications\nPCI control #6 emphasizes the importance of implementing robust security measures throughout the development and maintenance life cycle of systems and applications. This control aims to safeguard sensitive data by ensuring that secure coding practices, vulnerability management, and access controls are in place. Falco, with its runtime security and behavioral monitoring capabilities, can significantly contribute to meeting this control.\nBy continuously monitoring containerized environments, Falco can detect security events, which helps engineering teams enforce secure configurations, identify potential vulnerabilities, and provide real-time insights into system and application behavior. Its ability to generate real-time alerts, trigger automated responses, and integrate with other security tools empowers organizations to develop and maintain secure systems and applications that align with PCI requirements.\nPCI Sub-Control #6.4.2 Separation of duties between development/test environments\nThe Falco rule \u0026quot;Network Connection Outside Local Subnet,\u0026quot; is an excellent example of how Falco can be utilized to detect the separation of duties between development/test environments for containerized workloads, specifically in the context of PCI control 6.4.2.\nThe PCI control 6.4.2 focuses on ensuring that development/test environments are segregated from production environments in order to minimize the risk of unauthorized access or data leakage. By monitoring network connections within containerized environments, Falco can play a crucial role in enforcing this control.\nThe local subnet network connection rule is designed to alert whenever a container attempts to establish unwarranted network connections. This indicates that a container in the development/test environment is trying to communicate with resources outside its designated network boundaries. Such communication might be a sign of misconfiguration, unauthorized access attempts, or a potential data exfiltration attempt.\nWhen Falco detects a network connection outside the local subnet, it generates an alert or takes a defined action, such as logging the event, sending notifications to security personnel, or triggering automated responses. This allows security teams to identify and investigate any suspicious activities that violate the separation of duties between development/test and production environments.\n- rule: Network Connection outside Local Subnet desc: Detect traffic to image outside local subnet. condition: \u0026gt; inbound_outbound and container and not network_local_subnet and k8s.ns.name in (namespace_scope_network_only_subnet) enabled: false output: \u0026gt; Network connection outside local subnet (command=%proc.cmdline pid=%proc.pid connection=%fd.name user=%user.name user_loginuid=%user.loginuid container_id=%container.id image=%container.image.repository namespace=%k8s.ns.name fd.rip.name=%fd.rip.name fd.lip.name=%fd.lip.name fd.cip.name=%fd.cip.name fd.sip.name=%fd.sip.name) priority: WARNING tags: [container, network, mitre_discovery, PCI_DSS_6.4.2] By implementing this Falco rule, organizations can ensure that containers in development/test environments adhere to the principle of isolation and prevent potential security breaches or data leaks. It provides an additional layer of security by actively monitoring and alerting on any network connections that violate the defined boundaries, thus aligning with PCI control 6.4.2 requirements.\nOverall, leveraging Falco's rule-based approach and real-time monitoring capabilities, organizations can effectively detect and respond to any attempts to breach the separation of duties between development/test and production environments, helping to maintain a secure containerized ecosystem in accordance with PCI standards.\nPCI Control #10 Track and monitor all access to network resources \u0026amp; cardholder data\nPCI DSS Requirement #10 emphasizes the need for organizations to implement comprehensive logging and monitoring capabilities to track and monitor access to network resources and cardholder data. Thankfully, Falco can track and monitor network traffic, container activities, and access to sensitive data within cloud-native environments. Falco generates alerts and logs based on predefined rules and policies, providing visibility into potentially suspicious or unauthorized activities.\nPCI Sub-Control #10.2.5 Usage and modification of identification \u0026amp; authentication mechanisms\nThe specific PCI sub-control 10.2.5 focuses on ensuring that organizations implement secure and controlled mechanisms for user identification and authentication. Falco's capability to detect the launch of privileged containers can greatly assist in meeting this control requirement.\nWhen Falco detects the launch of privileged containers, it signifies that containers with elevated privileges or escalated access rights are being created within the environment. This can be an indication of potential security risks, as privileged containers may bypass normal security controls or introduce vulnerabilities if misused or compromised.\nBy actively monitoring container orchestration platforms, such as Kubernetes, Falco can generate alerts when privileged containers are spawned. Security teams can then investigate the event, ensuring that proper authentication and access controls are in place for such containers. This includes verifying that appropriate authorization mechanisms, such as strong user authentication and secure access controls, are applied to privileged containers:\n- rule: Launch Privileged Container desc: Detect the initial process started in a privileged container. Exceptions are made for known trusted images. condition: \u0026gt; container_started and container and container.privileged=true and not falco_privileged_containers and not user_privileged_containers and not redhat_image output: Privileged container started (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline) priority: INFO tags: [container, privilege_escalation, lateral_movement, T1610, PCI_DSS_10.2.5] Falco provides the capability to identify the creation of previously unrecognized privileged containers that are not included in its known list (defined by the user_privileged_containers macro). This ensures that if a new privileged container is spawned, the security team is alerted and given the opportunity to thoroughly review the activity and initiate appropriate actions, if needed.\nBy detecting these unknown privileged containers, Falco enhances the overall security posture by enabling proactive monitoring to address the sub-control 10.2.5. This helps to maintain the integrity and security of access controls, which is needed to safeguard sensitive cardholder data.\nPCI Control #11 Regularly test security systems \u0026amp; processes\nPCI control 11 highlights the importance of conducting regular assessments and evaluations to ensure the effectiveness of security systems and processes. By conducting regular security testing, including penetration testing and code reviews, organizations can identify potential security gaps, validate the effectiveness of security controls, and strengthen their overall security posture. PCI control 11 ensures that security measures remain robust, evolving alongside emerging threats and vulnerabilities.\nPCI Sub-Control #11.5.1 Implement a Process to Respond to Any Alerts Generated by a Change-Detection Solution\nThe below Container Drift rule can be used to address PCI control 11.5.1, which emphasizes the implementation of a process to respond to alerts generated by changes.\nWhen the \u0026quot;Drop and execute new binary in container\u0026quot; rule is triggered, it indicates that there has been a modification to the executable content currently running in a container. This kind of change should not happen in containers that are designed with the Principle of Immutability in mind and may be a strong indication of unauthorized or unexpected actions within the container environment. It is crucial to respond to such alerts promptly to ensure the integrity and security of the system.\n- rule: Drop and execute new binary in container desc: Detects if an executable not belonging to the base image of a container is being executed. The drop and execute pattern can be observed after an attacker gained an initial foothold. is_exe_upper_layer filter field only applies for runtimes using overlayfs as union mount fs. condition: \u0026gt; spawned_process and container and proc.is_exe_upper_layer=true and not container.image.repository in (known_drop_and_execute_containers) output: \u0026gt; Executing binary not part of base image (user=%user.name user_loginuid=%user.loginuid proc.exepath=%proc.exepath proc.cwd=%proc.cwd proc.vpgid=%proc.vpgid evt.res=%evt.res) priority: CRITICAL tags: [container, mitre_persistence, TA0003, PCI_DSS_11.5.1] Falco's real-time alerting capability enables organizations to receive immediate notifications when cases of drift occur, allowing DevOps \u0026amp; DevSecOps engineers to seamlessly integrate these alerts into a robust incident response process. In the context of PCI control 11.5.1, organizations can establish a predefined response procedure for handling such alerts.\nThe rule itself is triggered when a new binary is dropped and executed within a container. The remediation process might involve investigating the source of the file permission change, assessing the impact on the container and the surrounding environment, and taking appropriate mitigation measures.\nBy leveraging the insights provided by Falco's container drift rules, users can implement a proactive incident response process that aligns with PCI control 11.5.1. Responding to alerts promptly helps to address any unauthorized changes and ensures that security systems and processes remain intact, protecting cardholder data and maintaining compliance with PCI requirements.\nConclusion PCI DSS sets forth many security requirements with prescriptive validations and guidance. It serves as a comprehensive standard for organizations that must safeguard cardholder data and ensure secure payment card transactions. Meeting each requirement and sub-requirement is crucial for achieving PCI DSS compliance, avoiding financial penalties from the PCI Security Standards Council, mitigating the risk of data breaches and fraud.\nWhile Falco does not provide inherent data protection mechanisms, it plays a vital role as a detection tool for cardholder data environments, enabling organizations to identify potential risks and breaches that could compromise stored cardholder data. By harnessing Falco's capabilities, organizations can promptly detect security incidents and take necessary actions to protect sensitive information or initiate appropriate responses as defined in the PCI DSS.\nThis guidance focuses on 3 areas of security requirements (#6, #10 and #11). It serves as a foundation for understanding how Falco can be leveraged to detect insecure behaviors that may result in a failed PCI DSS audit. Future articles will delve into the remaining PCI DSS controls. It is essential to emphasize that even a single failed control can have severe financial and reputational consequences for organizations.\nAs usual, if you have any feedback or need help, you can find us at any of the following locations.\nGet started in Falco.org Check out the Falco project on GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":null,"title":"PCI/DSS Controls with Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-pci-controls/"},{"category":"blog","content":"The release of Falco 0.35.0 is a significant milestone, introducing a groundbreaking feature: the ability to select which syscalls to monitor. This empowers users with granular control, optimizing system performance by reducing CPU load through selective syscall monitoring.\nWhy stop at just the one groundbreaking feature, such as selecting which syscalls to monitor? Previously, Falco was limited to monitoring a narrower set of syscalls, which was a drawback since its underlying libraries and kernel drivers were capable of monitoring a wider range of syscalls. We addressed this gap, and Falco now has the enhanced capability to monitor every syscall supported by its libraries. This milestone, allowing access to a notable range of syscalls, represents another significant advancement in threat detection.\nKudos to the remarkable teamwork of Jason Dellaluce, Federico Di Pierro, Andrea Terzolo, and Melissa Kilby for making the adaptive syscalls selection feature a reality. We would also like to express our gratitude to Stanley Chan for providing invaluable feedback to ensure a clear and user-friendly experience.\nKey Terms First, let's define key terms that are crucial for understanding the complexity and high-level nature of the refactoring that has been performed.\nsyscall: In Linux, system calls serve as the interface for requesting permission from the kernel to interact with hardware resources, such as accessing memory or reading files. These system calls are defined in the Linux headers, and each syscall is associated with a specific number, such as __NR_close. Falco, being designed to support multiple architectures internally, employs a mapping mechanism to track each system call using a custom invented code called PPM_SC_*. This mapping allows Falco's libraries to uniquely identify and handle each supported syscall in a uniform manner. (e.g. PPM_SC_CLOSE represents the close syscall).\nevent: Syscalls consist of an enter event and an exit event. This is why Falco introduces an additional mapping from the PPM_SC_* code to another enumeration called PPME_*, which is specific to Falco's libraries. This mapping is crucial for organizing the parsing process and ensuring a structured approach, especially because Falco not only handles syscall events but also deals with non-syscall events. For syscalls, specific codes are assigned to events like the enter event of the syscall (e.g. PPME_SYSCALL_CLOSE_E) and the exit event (e.g. PPME_SYSCALL_CLOSE_X). However, not every syscall has its own PPME_* code. Falco introduces the concept of generic syscalls, which brings the advantage of a shared schema and parsing mechanism for multiple syscalls using a generic extractor, optimizing efficiency by avoiding the need for separate parsers in those cases.\nmonitoring/tracing: Refers to passively observing and analyzing events within the Linux kernel by hooking into tracepoints and subsequently serving information up as structured Falco alerts. Falco's monitoring process does not influence or modify any syscalls.\nprocessing/parsing: Extracting meaningful information from the events captured by Falco and converting them into a structured format. We extract data fields in the kernel and perform the necessary parsing in userspace.\nfiltering: Refers to stopping the processing / parsing or ignoring events. No modifications are made to the kernel during this process.\nrules matching: Refers to evaluating an event in userspace against the Abstract Syntax Tree (AST) generated from a Falco rule.\nBackground Before the 0.35.0 release, Falco would monitor a predefined set of commonly used syscalls in its kernel driver for threat detection, regardless of the specific rules being applied. However, this approach had limitations as it would monitor a large number of syscalls. In certain user configurations, Falco would needlessly monitor syscalls not relevant to the loaded rules, consuming system resources without effectively contributing to the intended purpose of threat detection.\nYou may ask yourself why Falco has been monitoring a predetermined set of commonly used syscalls until now. Falco relies on a set of syscalls to establish and maintain its state in userspace. For example, when a new process is spawned or a network connection is created, multiple syscalls are involved. Additionally, Falco maintains a process cache table in userspace, which requires tracking certain syscalls to ensure the accuracy and currency of the cache table. The process table is crucial for retrieving real-time process tree lineages and other functions.\nInitially, tracing a predefined set of syscalls provided a solid foundation for Falco's functionality. However, with the growing computational workload on servers and systems, it became necessary to adopt a new and more efficient approach to optimize performance.\nAdaptive Syscall Selection Adaptive syscall selection is a new feature that adds the ability to select which syscalls to monitor. This empowers users with granular control, optimizing system performance by reducing CPU load through selective syscall monitoring. Adaptive syscall selection was added to Falco on version 0.35, and, by default, it doesn't change Falco behavior from a high-level view. In other words, by default, Falco continues to operate as usual.\nThe changes primarily impact the handling of syscall events and the selection of specific syscalls to be monitored and analyzed. The current changes only affect live syscall events. The sycall selection is now done as follows:\nFalco determines a base set of syscalls to monitor. This can be either the default minimum set known as the \u0026quot;sinsp state set\u0026quot; (automatically determined by the underlying libsinsp library to maintain state consistency and stability), or a customized set of syscalls defined by the user via the new base_syscalls configuration (discussed later). The final set of syscalls selected by Falco is determined as the union of two components: the base set of syscalls computed in the previous step, and the syscalls specified in the loaded rules. If the -A flag is not enabled, performance-heavy syscalls, such as I/O-intensive syscalls, are excluded from the set of syscalls, and a warning is shown to the user. Falco configures the kernel driver with the chosen set of syscalls and only monitors syscalls that match the selected syscalls on the kernel side. Adaptive syscall selection does not apply to capture files and only affects the behavior of live capture.\nNew Configuration Options As discussed above, Falco 0.35 allows users to define a customized base set of syscalls to monitor. This is done via the base_syscalls setting, which provides two configuration options:\nThe custom_set option enables users to define a custom list of syscalls to monitor in Falco in addition to the syscalls from each Falco rule. It supports both positive notation, where a syscall is specified to be activated, and negative notation, indicated by ! followed by the syscall name, to deactivate a syscall even if it is used in the ruleset. This flexibility allows users to have precise control over which syscalls are included or excluded in the sys_enter and sys_exit tracepoints, ensuring a tailored configuration that aligns with their specific requirements, use cases and cost budget.\nTo maintain a streamlined and efficient configuration, it is recommended to remove unwanted syscalls directly from the Falco rules instead of excluding them in the custom_set configuration. This approach ensures that the rules accurately reflect the desired behavior and reduces unnecessary complexity in the configuration.\nWhen the repair option is set to true, it automatically adjusts the custom syscall set to ensure the accurate creation of its state engine, including necessary syscalls such as close or procexit. However, it is designed to be the most system resource-friendly by activating the least number of additional syscalls (outside of those enabled for enabled rules) as alternative to Falco's default libsinsp state engine enforcement. It dynamically selects necessary syscalls based on the active rules, making it truly adaptive and efficient. The repair_state feature helps mitigate issues that may arise from incorrect usage of custom_set.\nHere are some helpful suggestions:\nFor process-related rules include syscalls such as clone, clone3, fork, vfork, execve, execveat, and close in the base_syscalls.custom_set; these syscalls are essential for retrieving process information and managing file descriptors.\nFor networking-related rules include syscalls like socket, bind, and getsockopt in the base_syscalls.custom_set; these syscalls ensure that network-related events are properly logged, including IP tuples and relevant information.\nFor tracking process information accurately consider adding syscalls such as setresuid, setsid, setuid, setgid, setpgid, setresgid, setsid, capset, chdir, chroot, prctl and fchdir; these syscalls help track the correct UID, GID, SID, and PGID etc of a process when it interacts with files or makes network connections.\nThe provided suggestions serve as a starting point for configuring the base_syscalls.custom_set according to users' specific monitoring needs. It is crucial to assess these suggestions within the context of individual use cases and make appropriate adjustments.\nBy adhering to these recommendations and carefully fine-tuning the syscall selection, users can achieve optimal performance, minimize resource utilization and possible kernel side event drops, and maintain precise monitoring and detection of potential security threats with Falco. Tailoring the syscall selection aligns Falco with the unique requirements of the environment, enhancing its effectiveness in threat detection.\nFor further information, please refer to the Falco configuration file and navigate to the new base_syscalls option: https://github.com/falcosecurity/falco/blob/master/falco.yaml\nIf all of this sounds confusing or unclear, the best way to gain a deeper understanding of this new feature is through hands-on experimentation. By actively exploring and testing the feature, you can observe firsthand how it can enhance the performance of your deployment.\nAlso, you can test it live in this interactive environment that we have prepared for you.\nClick on it to start playing with it 🎮\nIf you wish to examine the final set of syscalls that will be used by Falco on your own envinronment, you can print them to the STDOUT by including the -o \u0026quot;log_level=debug\u0026quot; -o \u0026quot;log_stderr=true\u0026quot; --dry-run args during a dry run of Falco. By utilizing this option, you can gain valuable insights into the selected syscalls, aiding in troubleshooting and verifying the configuration.\n❯ falco -o \u0026#34;log_level=debug\u0026#34; -o \u0026#34;log_stderr=true\u0026#34; --dry-run Tue May 30 14:01:27 2023: Falco version: 0.35.0-alpha5 (x86_64) Tue May 30 14:01:27 2023: CLI args: falco -o log_level=debug -o log_stderr=true --dry-run Tue May 30 14:01:27 2023: Falco initialized with configuration file: /etc/falco/falco.yaml Tue May 30 14:01:27 2023: Configured rules filenames: Tue May 30 14:01:27 2023: /etc/falco/falco_rules.yaml Tue May 30 14:01:27 2023: /etc/falco/falco_rules.local.yaml Tue May 30 14:01:27 2023: /etc/falco/rules.d Tue May 30 14:01:27 2023: Loading rules from file /etc/falco/falco_rules.yaml Tue May 30 14:01:27 2023: Loading rules from file /etc/falco/falco_rules.local.yaml Tue May 30 14:01:27 2023: Skipping daemonizing in dry-run Tue May 30 14:01:27 2023: Skipping signal handlers creation in dry-run Tue May 30 14:01:27 2023: Skipping daemonizing in dry-run Tue May 30 14:01:27 2023: Setting metadata download max size to 100 MB Tue May 30 14:01:27 2023: Setting metadata download chunk wait time to 1000 μs Tue May 30 14:01:27 2023: Setting metadata download watch frequency to 1 seconds Tue May 30 14:01:27 2023: Skipping clients initialization in dry-run Tue May 30 14:01:27 2023: (32) syscalls in rules: accept, accept4, connect, creat, dup, dup2, dup3, execve, execveat, link, linkat, listen, mkdir, mkdirat, open, openat, openat2, ptrace, recvfrom, rename, renameat, renameat2, rmdir, sendmsg, sendto, setuid, socket, symlink, symlinkat, unlink, unlinkat, userfaultfd Tue May 30 14:01:27 2023: +(40) syscalls (Falco\u0026#39;s state engine set of syscalls): bind, capset, chdir, chroot, clone, clone3, close, epoll_create, epoll_create1, eventfd, eventfd2, fchdir, fcntl, fork, getsockopt, inotify_init, inotify_init1, io_uring_setup, mount, open_by_handle_at, pipe, pipe2, prctl, prlimit, procexit, recvmsg, setgid, setpgid, setresgid, setresuid, setrlimit, setsid, shutdown, signalfd, signalfd4, socketpair, timerfd_create, umount, umount2, vfork Tue May 30 14:01:27 2023: (72) syscalls selected in total (final set): accept, accept4, bind, capset, chdir, chroot, clone, clone3, close, connect, creat, dup, dup2, dup3, epoll_create, epoll_create1, eventfd, eventfd2, execve, execveat, fchdir, fcntl, fork, getsockopt, inotify_init, inotify_init1, io_uring_setup, link, linkat, listen, mkdir, mkdirat, mount, open, open_by_handle_at, openat, openat2, pipe, pipe2, prctl, prlimit, procexit, ptrace, recvfrom, recvmsg, rename, renameat, renameat2, rmdir, sendmsg, sendto, setgid, setpgid, setresgid, setresuid, setrlimit, setsid, setuid, shutdown, signalfd, signalfd4, socket, socketpair, symlink, symlinkat, timerfd_create, umount, umount2, unlink, unlinkat, userfaultfd, vfork Tue May 30 14:01:27 2023: The chosen syscall buffer dimension is: 8388608 bytes (8 MBs) Tue May 30 14:01:27 2023: Skipping starting webserver in dry-run Tue May 30 14:01:27 2023: Skipping event processing in dry-run Tue May 30 14:01:27 2023: Skipping unregistering signal handlers in dry-run Tue May 30 14:01:27 2023: Skipping stopping webserver in dry-run Refactors Involved This section provides an overview of the underlying refactors that have enabled the implementation of the innovative adaptive syscall selection mechanisms in Falco.\nFalco's ppm sc API A new event set class has been introduced to support efficient set operations natively in the ppm sc API in Falco's libs.\nAdditional refinements in the ppm sc API have resulted in robust mechanisms to accurately map syscall and other event strings from the loaded Falco rules to the PPM_SC_* or PPME_* enumerations.\nThis enhancement was essential to overcome the challenges inherited from previous mapping processes and improve the efficiency and structure of event parsing.\nThe initial separate enumeration for kernel tracepoints has been merged with the PPM_SC_* codes (sc now reflecting scap codes instead of syscall codes only), resulting in a single enumeration.\nThis consolidation sets the groundwork for integrating future LSM (Linux Security Modules) hooks into Falco. By combining these codes, Falco achieves a seamless integration of tracepoint activations and syscall event handling within a unified framework.\nSyscall Event Type Extraction from Falco's Rules Expression Language In order to extract the corresponding event types, Falco traverses the filter Abstract Syntax Tree (AST) of each rule. The traversal process has been improved for robustness and integrated with the modernized ppm sc API by moving it to the underlying Falco libs.\nAdditionally, traversals now include support for mapping the rules event strings to both the PPM_SC_* and PPME_* codes. These changes have allowed for the resolution of technical debt concerning the mapping of event strings to their respective syscall codes.\nJust to emphasize this once more: Falco now has the capability to support any syscall that is supported by its underlying libraries. This expansion of support allows Falco to monitor and analyze a wider range of syscalls for threat detection purposes (see Falco's supported syscalls).\nDriver Syscall Push Down Filters After mapping the event strings from the rules to their corresponding syscall IDs, we utilize a dedicated eBPF map (in the case of *bpf* drivers) or an internal bitmask using the ioctl API (in the case of kernel module) to inject this information into the sys_enter and sys_exit tracepoints within the driver.\nDue to the triggering of the sys_enter and sys_exit kernel tracepoints for every syscall, our pushdown filter is designed to efficiently ignore unnecessary syscalls before any data field extraction takes place in our kernel drivers. Once again, Falco operates as a passive monitor of syscalls and does not exert any influence or modify the behavior of the syscalls being monitored.\nFurthermore, the objective of kernel-side filtering is to minimize the number of events that need to be transferred to userspace via the buffer between kernel and userspace, as well as reduce the number of events that are processed and evaluated against Falco rules in userspace.\nThis filtering allows us to achieve these efficiencies without sacrificing visibility, as the ignored syscalls are not utilized in Falco rules.\nSpoiler alert: Imagine a monitoring experience where Falco adapts in real-time, intelligently adjusting its capabilities as needed. The ppm sc API already allows you to dynamically enable or disable syscalls and tracepoints at runtime.\nThis opens up exciting possibilities for the future of Falco. One day, we envision a truly adaptive monitoring system where Falco can supervise itself and automatically adjust the level of logging verbosity on the fly based on the system's needs.\nUserspace libsinsp State Engine By efficiently extracting syscall codes from Falco rules strings, we no longer need a large hard-coded predetermined set of syscalls.\nAs mentioned previously, the remaining task involved enabling all the syscalls required for the libsinsp state that were not explicitly included in the Falco rules. This is where the new base_syscalls configuration comes into play, providing end users with complete control over this process.\nWith the base_syscalls configuration, users can define and activate the necessary syscalls for the libsinsp state, ensuring comprehensive monitoring and threat detection capabilities.\nAction Items and Recommendations for Adopters Review the updated falco.yaml file for performance tuning configurations. Assess if performance optimizations are needed based on your threat model and budget. Adjust the base_syscalls configuration accordingly. Gradually tailor the base_syscalls configuration as needed, aiming to optimize resource utilization without compromising threat detection, if feasible. Experiment and measure changes in resource usage by utilizing the native Falco metrics option. Enhance Falco rules with specific syscalls for increased robustness [see note 1]. Official syscall string names in rules are now required. Explore new threat detection approaches with Falco's expanded syscall support. Stay updated on future releases for enhanced kernel monitoring capabilities. One concrete example is the rule named \u0026quot;Linux Kernel Module Injection Detected.\u0026quot; Previously, this rule relied on monitoring spawned processes. However, with the broader syscall coverage, it is now possible to enhance the rule by focusing on specific syscalls such as init_module and finit_module, which are directly related to kernel module injection.\n","summary":"","tags":["Falco Libs","Falco"],"title":"Adaptive Syscalls Selection in Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/adaptive-syscalls-selection/"},{"category":"blog","content":"Today we announce the release of Falco 0.35.1 🦅!\nNovelties 🆕 and Fixes Here is a tiny patch release! It addresses some small bugs that will not bother us and our users anymore:\nBug fix in the plugin framework, we can now associate a thread ID also to async events so that we can access related juicy information when writing rules! We suggest updating to this version to be able to use all the new capabilities that the new Plugin API has to offer! Modern BPF can now be used in least privileged mode without any trouble in COS Driver loader now correctly parses the kernel version of Ubuntu’s kernel flavors, and also supports Debian rt and cloud Solved a rule ordering problem on our default ruleset that caused some rules to be shadowed Updated falcoctl to the latest version, which fixes a corner cases that cause the tool to freeze Thanks to everyone in the community for helping us in spotting these annoying bugs 🐛! You make Falco successful 🦅!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nTry it! 🏎️ As usual, in case you just want to try out the stable Falco 0.35.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader What's next 🔮 We are in the working to let new big things happen in Falco, stay tuned!\nLet's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nJason and Lorenzo\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.35.1","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-35-1/"},{"category":"blog","content":"Recently, a significant compromise was discovered in a user environment, revealing a fascinating cloud operation called SCARLETEEL. This operation was responsible for the theft of valuable proprietary data. The attacker's strategy involved exploiting a containerized workload, utilizing it as a springboard for privilege escalation within an AWS account, and ultimately pilfering proprietary software and credentials. Notably, they also made attempts to expand their influence across the organization by leveraging a Terraform state file to access other interconnected AWS accounts.\nWhat sets this attack apart from others is its elevated level of sophistication. It originated from a compromised Kubernetes container and propagated into the victim's AWS account. Moreover, the attackers exhibited a deep understanding of AWS cloud mechanisms, including Elastic Compute Cloud (EC2) roles, Lambda serverless functions, and Terraform. It is important to note that their intentions surpassed the typical objectives of a cryptojacking attack, as their primary goal was the theft of proprietary software.\nAlignment of Falco and MITRE ATT\u0026amp;CK\nThis sophisticated attack underscores the imperative of aligning with MITRE ATT\u0026amp;CK principles for containers and the cloud. By embracing these principles, organizations can gain a better understanding of the intricate security challenges faced by cloud native systems. The CNCF Falco project, with its extensive collection of preconfigured rules, offers a valuable resource for addressing the insecure behaviors associated with such attacks.\nFalco's workload/host-based capabilities were recently added to the Tidal Cyber Product Registry. The community now has a greater ability to operationalize the rules while implementing threat-informed defense using Tidal Cyber's Community Edition, a freely-available platform that makes threat and adversary behavior research easy. A summary of the capabilities can be found here. A Technique Set summarizing \u0026amp; visualizing the ATT\u0026amp;CK-mapped SCARLETEEL techniques described here was also added to the Community Edition Community Spotlight here:\nThis attack was originally discovered by the Sysdig Threat Research team, and more details can be found in their blog documenting SCARLETEEL.\nOverview of the Attack The following diagram shows the main steps in the kill chain. Let's first show the attack at a high level, then provide greater detail of each state:\nStep 1: The attacker gained initial access by exploiting a public-facing service in a self-managed Kubernetes cluster hosted inside an AWS cloud account.\nStep 2: Once the attacker gained access to the Pod, the malware was able to perform two initial actions during execution:\nLaunch a crypto miner in order to make money or provide a distraction. Obtain credential access through a worker's temporary credentials in Instance Metadata Service (IMDS) v1 to enumerate and collect information on its behalf using the cluster role permissions. Due to excessive granted permissions, the attacker was able to:\nEnumerate AWS resources. Find credentials of other identity and access management (IAM) users both set as Lambda environment variables and pushed in plain text to Amazon Simple Storage Service (S3) buckets. Step 3: The attacker used the credentials found in the previous step to move laterally. They directly contacted the AWS API, further enumerated the account, and proceeded with information gathering and data exfiltration. During this step, they were able to:\nDisable CloudTrail logs to evade detection. Steal proprietary software. Find the credentials of an IAM user related to a different AWS account by discovering Terraform state files in S3 buckets. Step 4: The attacker used the new credentials to move laterally again, repeating the attack and their kill chain from the other AWS account they found. Fortunately, in this case they were not able to enumerate resources, since all of the AWS API requests they attempted failed due to a lack of permissions.\nTechnical Analysis Initial Access – Container Compromise The attacker successfully identified and exploited an internet-facing service that was deployed within a Kubernetes cluster. With access to the compromised container, they initiated a series of actions to further their attack objectives.\nTheir initial course of action involved the download and execution of a mining script to illicitly obtain memory cycles. The attacker executed the script miner.sh, which triggered the execution of an XMRig executable, accompanied by the miner configuration file config_background.json.\nIt is worth noting that while this behavior is not enabled by default, Falco offers a readily available rule that can detect outbound connections to commonly used miner pool ports or domains. As the connection had already been established in this scenario, the detection falls under the MITRE Execution technique, identified by the associated technique ID 'T1496'.\n- rule: Detect outbound connections to common miner pool ports desc: Miners typically connect to miner pools on common ports. condition: net_miner_pool and not trusted_images_query_miner_domain_dns enabled: false output: Outbound connection to IP/Port flagged by https://cryptoioc.ch (command=%proc.cmdline pid=%proc.pid port=%fd.rport ip=%fd.rip container=%container.info image=%container.image.repository) priority: CRITICAL tags: [host, container, network, mitre_execution, T1496] This rule can be surfaced in Tidal Community Edition's Product Registry here.\nCryptomining is probably the most common example of resource hijacking. However, the purpose of the attack went far beyond cryptomining. Either cryptomining was the attacker's initial goal and the goal changed once they accessed the victim's environment, or cryptomining was used as a decoy to evade the detection of data exfiltration.\nDuring the installation of the cryptominer, the threat research team observed a bash script running simultaneously on the container to enumerate and extract additional information in the environment, such as credentials. Since Falco handles system calls, we can get the same, deep level of visibility into running scripts in containers as we do on the host system.\n- rule: Run shell untrusted desc: an attempt to spawn a shell below a non-shell application. Specific applications are monitored. condition: \u0026gt; spawned_process and shell_procs and proc.pname exists and protected_shell_spawner and not proc.pname in (shell_binaries, gitlab_binaries, cron_binaries, user_known_shell_spawn_binaries, needrestart_binaries, mesos_shell_binaries, erl_child_setup, exechealthz, PM2, PassengerWatchd, c_rehash, svlogd, logrotate, hhvm, serf, lb-controller, nvidia-installe, runsv, statsite, erlexec, calico-node, \u0026#34;puma reactor\u0026#34;) and not proc.cmdline in (known_shell_spawn_cmdlines) and not proc.aname in (unicorn_launche) and not consul_running_net_scripts and not consul_running_alert_checks and not nginx_starting_nginx and not nginx_running_aws_s3_cp and not run_by_package_mgmt_binaries and not serf_script and not check_process_status and not run_by_foreman and not python_mesos_marathon_scripting and not splunk_running_forwarder and not postgres_running_wal_e and not redis_running_prepost_scripts and not rabbitmq_running_scripts and not rabbitmqctl_running_scripts and not run_by_appdynamics and not user_shell_container_exclusions output: \u0026gt; Shell spawned by untrusted binary (user=%user.name user_loginuid=%user.loginuid shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline pid=%proc.pid pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] aname[4]=%proc.aname[4] aname[5]=%proc.aname[5] aname[6]=%proc.aname[6] aname[7]=%proc.aname[7] container_id=%container.id image=%container.image.repository) priority: DEBUG tags: [host, container, process, shell, mitre_execution, T1059.004] This rule can be surfaced in Tidal Community Edition's Product Registry here.\nIn order to find credentials, the attacker directly accessed IMDS. IMDS v1 is the version used by default when creating older versions of self-managed clusters or EC2 instances in AWS. It's used to configure and manage machines.\nRetrieving AWS temporary security credentials bound to the EC2 instance role from IMDS v1 is a very well-known practice. The attacker was looking to discover the IAM role bound to the worker instance in order to obtain the AccessKeyId, SecretAccessKey, and temporary token.\nThe attacker targeted both the instance metadata endpoints and what commands were executed by the malicious script in order to grep and retrieve the IAM role keys. On EC2 instances, 169.254.169.254 is a special IP used to fetch metadata about the instance. It may be desirable to prevent access to this IP from containers.\n- rule: Contact EC2 Instance Metadata Service From Container desc: Detect attempts to contact the EC2 Instance Metadata Service from a container condition: outbound and fd.sip=\u0026#34;169.254.169.254\u0026#34; and container and not ec2_metadata_containers output: Outbound connection to EC2 instance metadata service (command=%proc.cmdline pid=%proc.pid connection=%fd.name %container.info image=%container.image.repository:%container.image.tag) priority: NOTICE enabled: false tags: [network, aws, container, mitre_discovery, T1565] This rule can be surfaced in Tidal Community Edition's Product Registry here.\nOnce collected, it is possible to use those credentials for a short period of time in order to run operations on behalf of the impersonated IAM role, calling the AWS API directly. Using CloudTrail logs, the threat research team could see that the first API calls from the attacker were using the compromised cluster role.\nThe attacker ran some AWS actions to gain persistence on the AWS platform, trying to create new users, groups, and bind new access keys to existing IAM users. Since Falco can handle events from AWS CloudTrail, we can easily detect when new users and groups are created under suspicious circumstances.\n- rule: Create AWS user desc: Detect creation of a new AWS user. condition: ct.name=\u0026#34;CreateUser\u0026#34; and not ct.error exists output: A new AWS user has been created (requesting user=%ct.user, requesting IP=%ct.srcip, AWS region=%ct.region, new user created=%ct.request.username) priority: INFO tags: - cloud - aws - aws_iam source: aws_cloudtrail This rule can be surfaced in the Falco Plugin Registry repository here.\nFortunately, all of these executions were denied because of a lack of permissions on the account the attacker was using. Unfortunately, the AWS cluster role was misconfigured with excessive read permissions.\nThe original intent was to allow the reading of a specific S3 bucket, but the permissions allowed the role to read everything in the account, which enabled the attacker to gain further knowledge of the AWS account, including Lambda.\nDiscovery – AWS Cloud Once the attacker obtained initial access into the cloud account, they started gathering information about the resources deployed in the AWS account. The most common activities reported include the listing of AWS buckets. These API requests were recorded in the AWS account. Again, Falco rules are already curated for these scenarios:\n- rule: List Buckets desc: Detect listing of all S3 buckets. condition: ct.name=\u0026#34;ListBuckets\u0026#34; and not ct.error exists output: A list of all S3 buckets has been requested. (requesting user=%ct.user, requesting IP=%ct.srcip, AWS region=%ct.region, host=%ct.request.host) priority: WARNING enabled: false tags: - cloud - aws - aws_s3 source: aws_cloudtrail This rule can be surfaced in the Falco Plugin Registry repository here.\nDuring these scraping operations, the attacker focused their efforts on the most used AWS services: Serverless Lambda functions and S3 buckets.\nLambda Function Enumeration – Stolen Proprietary Code and Software Lambda functions and other serverless functions are commonly used to execute custom code without worrying about the infrastructure underneath, leaving a lot of flexibility for end users.\nThere were different Lambda functions in the affected AWS account, mainly related to account automation. The attacker started to enumerate and retrieve all of the Lambda functions located in a specific region in the AWS account using the proper API call.\nAfter obtaining the list of functions, the attacker tried to dig deeper by downloading the Lambda code. Calling the AWS API, they were able to get the code location so that they could download the code that makes up the Lambda. In this case, the Lambda function held proprietary software and the keys needed to execute it.\nUsing curl or wget commands, the attacker successfully exfiltrated the Lambda code and stole proprietary code and software from the Lambda functions. There was also evidence that the attacker executed the stolen software. They took the time to look at the Lambda function's environment variables and find additional AWS credentials related to IAM users in the same account. However, any attempts to tamper with the Lambda functions configuration would have been instantly detected by Falco:\n- rule: Update Lambda Function Code desc: Detect updates to a Lambda function code. condition: ct.name=\u0026#34;UpdateFunctionCode20150331v2\u0026#34; and not ct.error exists output: The code of a Lambda function has been updated. (requesting user=%ct.user, requesting IP=%ct.srcip, AWS region=%ct.region, lambda function=%ct.request.functionname) priority: WARNING tags: - cloud - aws - aws_lambda source: aws_cloudtrail This rule can be surfaced in the Falco Plugin Registry repository here.\nAs you will see in the next steps of the attack, adversaries used the credentials found here to retry enumeration with the new user, hoping for new findings or to evaluate possible privilege escalation inside the account.\nDefense Evasion – Disable CloudTrail Logging Once the attacker accessed the cloud account, they attempted to disable CloudTrail logs inside the compromised account. The attacker succeeded in disabling some of the logs configured in the account because of extra permissions assigned to one of the users compromised in the previous steps.\nSince Falco pre-processes all event data from Cloudtrail, we can also see when Cloudtrail audit logging is disabled in a specific AWS region.\n- rule: CloudTrail Logging Disabled desc: The CloudTrail logging has been disabled, this could be potentially malicious. condition: ct.name=\u0026#34;StopLogging\u0026#34; and not ct.error exists output: The CloudTrail logging has been disabled. (requesting user=%ct.user, requesting IP=%ct.srcip, AWS region=%ct.region, resource name=%ct.request.name) priority: WARNING tags: - cloud - aws - aws_cloudtrail source: aws_cloudtrail This rule can be surfaced in the Falco Plugin Registry repository here.\nAs a result of this action, it wasn't possible to continue retrieving additional attack evidence. When reviewing account permissions, it is critical to keep the ability to disable or delete security logs to as few users as possible. Deletion shouldn't even be possible in most situations without a solid backup solution.\nLateral Movement – AWS account With the new credentials acquired, the attacker restarted their enumeration and information-gathering process to determine whether they could gain additional resources from inside this additional compromised account. In addition, CloudTrail recorded suspicious activities in the connected AWS account mentioned above.\nThe attacker tried to perform enumeration on different AWS resources in the connected cloud account. Fortunately, the IAM user was very-well scoped, so all of the requests failed due to a lack of permissions, leaving just the harmless GetCallerIdentity API, which is permitted by default.\nConclusion The SCARLETEEL attack began by exploiting a vulnerable Pod and leveraging the associated IAM role's identity. The attacker then proceeded to conduct enumeration, search for sensitive data, and steal proprietary software using the compromised role. Upon discovering new credentials, they used them to establish persistence and attempt to gain further privileges.\nFollowing the detection of the attack, several measures were implemented to secure the environment. These included disabling and removing users' access keys and secret access keys, securing vulnerable applications through audits and penetration tests, restricting access to sensitive S3 buckets with stringent policies, and adopting additional least privilege measures to minimize the attack surface and impede lateral movement within the cloud.\nThis sophisticated attack serves as a stark reminder of the extent to which an attacker can exploit a vulnerable application lacking proper security measures. It reaffirms two crucial principles: the significance of zero trust and the principle of least privilege. By implementing these principles, the probability of compromise can be significantly reduced. Furthermore, robust detection mechanisms and timely alerts are essential in detecting and mitigating such activities before an attacker gains substantial access.\n","summary":"","tags":null,"title":"Defensive Capabilities for Container \u0026 Cloud Threats with Tidal","url":"https://v0-43--falcosecurity.netlify.app/blog/tidal-registry-release/"},{"category":"blog","content":"Hello Folks!, my name is Rohith, and I am thrilled to share my experiences and reflections on the first week of the Google Summer of Code (GSoC) period.\nThis is an exhilarating time for participants like myself as we embark on our coding journey and dive into the world of open source development.\nA huge thank you! to all the community members accepting me as one of them ❤️.\nMy Project: Falco Playground Falco is a security tool that comes with a rule language for its runtime security engine. However, there is currently no official and user-friendly integrated development environment (IDE) for writing and testing Falco rules. To address this gap, we propose a project that aims to add WebAssembly as a supported compilation target for Falco.\nBy using the Emscripten toolchain, we plan to create a web-based single-page application that serves as a development environment for security rules. This means you can write and test Falco rules right inside your browser without the need for any backend infrastructure. The end result will be similar to the Go Playground, where you can experiment with code in a seamless and accessible manner.\nThe project offers an exciting opportunity to explore various technologies within the cloud-native landscape. It involves working with low-level system code in close proximity to the Linux kernel, WebAssembly world, and engaging in frontend development for web application. By combining these different aspects, we aim to provide a convenient and comprehensive solution for developing Falco rules with ease.\nNew beginnings 🚀 By contributing to the project prior to the GSoC period, I had the opportunity to understand the project's ecosystem, gain insights into its development processes, and establish myself as a valuable member of the community. It provided me with a deeper understanding of the project's goals and challenges, enabling me to better align my proposed solutions and goals for the GSoC period.\nDuring this pre-GSoC contribution phase, Jason Dellaluce, my mentor, played a crucial role in guiding and supporting me. Jason provided valuable feedback on my early contributions, helped me navigate the project's codebase, and encouraged me to explore new areas for improvement. My ongoing collaboration with Jason played a crucial role in my development as a contributor, paving the way for a fruitful journey through GSoC.\nAs Week 1 of the official GSoC period began, my pre-GSoC contributions served as a foundation for diving deeper into the project. The knowledge and familiarity I gained before allowed me to hit the ground running and make meaningful progress from the very beginning. It also reinforced the strong mentor-mentee relationship with Jason, as we had already established a rapport and had a shared understanding of the project's context.\nHere is a summary of pull requests (PRs) I have submitted:\nPR #1: Test For command falco -i (ignore default events)\nDescription: The falcosecurity/testing repository contains regression a test suite for Falco and other tools in its ecosystem. I contributed by adding a new test case for Falco's help output when used with thie -i flag. I contributed to two other flags. PR #2: Semver check for RequiredAPIVersion values\nDescription: This pr checks if user's RequiredAPIVersion follows semver system and checks if is compatible with internally-supported API version PR #3: Feat: Support for memfd_create syscall\nDesciption: Whenever the kernel is updated and released, a new syscall or updated version of syscall may be added. This can create new vulnerabilities that can allow malicious activity from Falco to go undetected. Therefore, we need to update Falco's internal syscall table to address vulnerabilities. This PR adds support for the memfd_create syscall PR #4: Feat: Support for pidfd_getfd syscall\nDescription: Same as above, this PR adds support to the pidfd_getfd syscall Conclusions In conclusion, my early contributions to the project before the GSoC period commenced provided me with a head start, enabling me to make a more significant impact right from the start. The guidance and support from Jason, combined with my pre-GSoC involvement, allowed me to seamlessly transition into the official GSoC period and continue building upon my previous contributions.\nPlease stay tuned for updates and feel free to reach out to me via the CNCF Falco community channels. Your guidance, feedback, and support are invaluable.\nThank you all for your warm welcome, and here’s to an exciting and fruitful GSoC.\n","summary":"","tags":["Gsoc","Mentorship"],"title":"GSoC Week 1 Reflections","url":"https://v0-43--falcosecurity.netlify.app/blog/gsoc-2023-1st-week/"},{"category":"blog","content":" This post is is part of a series of articles about How to develop Falco plugins. It's addressed to anybody who would like to understand how plugins are written and want to contribute. See other articles:\nExtend Falco inputs by creating a Plugin: the basics Extend Falco inputs by creating a Plugin: Register the plugin Introduction In the previous posts (see the basics and register), we covered all the basics to develop a plugin and register it. In this article, we'll focus on the steps to build the OCI artifacts and distribute them on Github Packages.\nTo get more familiar with the OCI artifacts, you can read our blog posts about falcoctl and GitOps for rules\nIn the next sections we'll describe how to:\nset up a Github Actions workflow to: create a release with GoReleaser when a tag is pushed build the OCI artifacts of the plugin and its rules create the index.yaml used by falcoctl Requirements This tutorial is based on a Github repo, with the possibility to run workflows in Github Actions and store OCI artifacts in Github Packages. If you use a different system or even just private repositories, you'll need to adapt the examples to your context.\nTo make it work, you must have the code organization proposed in the basics post.\nGoReleaser GoReleaser is a famous tool to build and create releases for projects on Github or else. We'll use it to build and archive the binaries at each release.\nAt the root of your repo, create a .goreleaser.yaml file with the following content:\nbuilds: - env: - GODEBUG=cgocheck=0 main: ./plugin binary: lib{PLUGIN_NAME}.so goos: - linux goarch: - amd64 flags: -buildmode=c-shared checksum: name_template: \u0026#34;checksums.txt\u0026#34; With PLUGIN_NAME as the name of your plugin.\nMakefile Makefiles are a convenient way to script actions. We'll use it to pass all the required flags to create the final .so library files used by the Falco plugin framework:\nSHELL=/bin/bash -o pipefail GO ?= go NAME := {PLUGIN_NAME} OUTPUT := lib$(NAME).so ifeq ($(DEBUG), 1) GODEBUGFLAGS= GODEBUG=cgocheck=2 else GODEBUGFLAGS= GODEBUG=cgocheck=0 endif all: build clean: @rm -f lib$(NAME).so build: clean @$(GODEBUGFLAGS) $(GO) build -buildmode=c-shared -buildvcs=false -o $(OUTPUT) ./plugin With PLUGIN_NAME as the name of your plugin.\nYou can test it by running make build and see the lib{PLUGIN_NAME}.so appearing at the root of your folder.\nGithub Actions Workflow The first step is to create the .github/workflows folder and the release.yaml file describing our workflow.\nHeaders Each workflow starts with, at least, a name and a on:\nname: Release Plugins on: push: tags: - \u0026#39;[0-9]+\\.[0-9]+\\.[0-9]+\u0026#39; env: OCI_REGISTRY: ghcr.io PLUGIN_NAME: {PLUGIN_NAME} permissions: contents: write packages: write The workflow will be triggered each time a tag following semantic versioning (major.minor.patch) is created.\nOnce again PLUGIN_NAME is the name of your plugin, it will be set as env var to be reused all over the file. It's the only thing to adapt to your context. We also set the registry (Github Packages) URL with OCI_REGISTRY.\nThe permissions are required to allow Github Actions to read the content of your repo, create the release and push the artifacts into Github Packages.\nThe jobs Once we have set the \u0026quot;headers\u0026quot; of the workflow file, it's time to set the actions that will be run. We'll split them into 2:\nPublish the OCI artifacts Create the release Publish the OCI artifacts To publish the artifacts, we'll use falcoctl, the official CLI to manage Falco artifacts.\nThe steps to publishing the artifacts will be, in this order:\nGet the falcoctl sources Prepare the Go env Build falcoctl (guarantees the latest version) Get the plugin sources Build the plugin (.so file) Get the repo name in lower case Push the artifacts with all their tags: push the plugin push the rules with a dependency to the plugin jobs: publish-oci-artifacts: runs-on: ubuntu-latest steps: - name: Checkout Falcoctl Repo uses: actions/checkout@v3 with: repository: falcosecurity/falcoctl ref: 0.5.0 path: tools/falcoctl - name: Setup Golang uses: actions/setup-go@v4 with: go-version: \u0026#39;^1.20\u0026#39; cache-dependency-path: tools/falcoctl/go.sum - name: Build falcoctl run: make working-directory: tools/falcoctl - name: Checkout uses: actions/checkout@v3 with: path: plugin - name: Build the plugin run: make build working-directory: plugin - id: StringRepoName uses: ASzc/change-string-case-action@v5 with: string: ${{ github.repository }} - name: Upload OCI artifacts to GitHub packages run: | MAJOR=$(echo ${{ github.ref_name }} | cut -f1 -d\u0026#34;.\u0026#34;) MINOR=$(echo ${{ github.ref_name }} | cut -f1,2 -d\u0026#34;.\u0026#34;) DIR=$(pwd) cd plugin/ $DIR/tools/falcoctl/falcoctl registry push \\ ${{ env.OCI_REGISTRY }}/${{ steps.StringRepoName.outputs.lowercase }}/plugin/${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --config /dev/null \\ --type plugin \\ --version \u0026#34;${{ github.ref_name }}\u0026#34; \\ --tag latest --tag $MAJOR --tag $MINOR \\ --platform linux/amd64 \\ --requires plugin_api_version:2.0.0 \\ --depends-on ${{ env.PLUGIN_NAME }}-rules:${{ github.ref_name }} \\ --name ${{ env.PLUGIN_NAME }} \\ lib${{ env.PLUGIN_NAME }}.so cd rules/ $DIR/tools/falcoctl/falcoctl registry push \\ ${{ env.OCI_REGISTRY }}/${{ steps.StringRepoName.outputs.lowercase }}/ruleset/${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --config /dev/null \\ --type rulesfile \\ --version \u0026#34;${{ github.ref_name }}\u0026#34; \\ --tag latest --tag $MAJOR --tag $MINOR \\ --depends-on ${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --name ${{ env.PLUGIN_NAME }}-rules \\ ${{ env.PLUGIN_NAME }}_rules.yaml env: FALCOCTL_REGISTRY_AUTH_BASIC: ${{ env.OCI_REGISTRY }},${{ github.repository_owner }},${{ secrets.GITHUB_TOKEN }} Create the release GoReleaser can automatically generate a Changelog at the same time we publish the new artifacts. This step isn't imperative to generate the OCI artifacts but it's a good practice among Go developers. To achieve that, make sure to have a correct .goreleaser.yml file as explained here.\nrelease: runs-on: ubuntu-latest[0-9]+\\.[0-9]+\\.[0-9]+ steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Setup Golang uses: actions/setup-go@v3 with: go-version: \u0026#39;1.19\u0026#39; - name: Run GoReleaser uses: goreleaser/goreleaser-action@v4 with: version: latest args: release --clean --timeout 120m env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} LDFLAGS: \u0026#34;-buildmode=c-shared\u0026#34; GOPATH: /home/runner/go Final result name: Release Plugins on: push: tags: - \u0026#39;[0-9]+\\.[0-9]+\\.[0-9]+\u0026#39; env: OCI_REGISTRY: ghcr.io PLUGIN_NAME: {PLUGIN_NAME} permissions: contents: write packages: write jobs: publish-oci-artifacts: runs-on: ubuntu-latest steps: - name: Checkout Falcoctl Repo uses: actions/checkout@v3 with: repository: falcosecurity/falcoctl ref: 0.5.0 path: tools/falcoctl - name: Setup Golang uses: actions/setup-go@v4 with: go-version: \u0026#39;^1.20\u0026#39; cache-dependency-path: tools/falcoctl/go.sum - name: Build falcoctl run: make working-directory: tools/falcoctl - name: Checkout uses: actions/checkout@v3 with: path: plugin - name: Build the plugin run: make build working-directory: plugin - id: StringRepoName uses: ASzc/change-string-case-action@v5 with: string: ${{ github.repository }} - name: Upload OCI artifacts to GitHub packages run: | MAJOR=$(echo ${{ github.ref_name }} | cut -f1 -d\u0026#34;.\u0026#34;) MINOR=$(echo ${{ github.ref_name }} | cut -f1,2 -d\u0026#34;.\u0026#34;) DIR=$(pwd) cd plugin/ $DIR/tools/falcoctl/falcoctl registry push \\ ${{ env.OCI_REGISTRY }}/${{ steps.StringRepoName.outputs.lowercase }}/plugin/${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --config /dev/null \\ --type plugin \\ --version \u0026#34;${{ github.ref_name }}\u0026#34; \\ --tag latest --tag $MAJOR --tag $MINOR \\ --platform linux/amd64 \\ --requires plugin_api_version:2.0.0 \\ --depends-on ${{ env.PLUGIN_NAME }}-rules:${{ github.ref_name }} \\ --name ${{ env.PLUGIN_NAME }} \\ lib${{ env.PLUGIN_NAME }}.so cd rules/ $DIR/tools/falcoctl/falcoctl registry push \\ ${{ env.OCI_REGISTRY }}/${{ steps.StringRepoName.outputs.lowercase }}/ruleset/${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --config /dev/null \\ --type rulesfile \\ --version \u0026#34;${{ github.ref_name }}\u0026#34; \\ --tag latest --tag $MAJOR --tag $MINOR \\ --depends-on ${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --name ${{ env.PLUGIN_NAME }}-rules \\ ${{ env.PLUGIN_NAME }}_rules.yaml env: FALCOCTL_REGISTRY_AUTH_BASIC: ${{ env.OCI_REGISTRY }},${{ github.repository_owner }},${{ secrets.GITHUB_TOKEN }} release: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Setup Golang uses: actions/setup-go@v3 with: go-version: \u0026#39;1.19\u0026#39; - name: Run GoReleaser uses: goreleaser/goreleaser-action@v4 with: version: latest args: release --clean --timeout 120m env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} LDFLAGS: \u0026#34;-buildmode=c-shared\u0026#34; GOPATH: /home/runner/go Replace PLUGIN_NAME with the name of your plugin.\nindex.yaml file This file is used by falcoctl to know where to download your plugin and rules. Please read this blog post to understand better how it works.\nWe'll create our own file to allow like the following:\n- name: {PLUGIN_NAME} type: plugin registry: ghcr.io repository: {OWNER_NAME}/{REPO_NAME}/plugin/{PLUGIN_NAME} description: {DESCRIPTION} home: https://github.com/{OWNER_NAME}/{PLUGIN_NAME} keywords: - {PLUGIN_NAME} license: Apache-2.0 maintainers: - email: {OWNER_EMAIL} name: {OWNER_REAL_NAME} sources: - https://github.com/{OWNER_NAME}/{PLUGIN_NAME} - name: {PLUGIN_NAME}-rules type: rulesfile registry: ghcr.io repository: {OWNER_NAME}/{REPO_NAME}/ruleset/docker description: Rules for the {PLUGIN_NAME} plugin home: https://github.com/{OWNER_NAME}/{REPO_NAME}/tree/main/rules keywords: - {PLUGIN_NAME} license: Apache-2.0 maintainers: - email: {OWNER_EMAIL} name: {OWNER_REAL_NAME} sources: - https://github.com/{OWNER_NAME}/{REPO_NAME}/tree/main/rules/{PLUGIN_NAME}_rules.yaml With:\nPLUGIN_NAME: the name of you plugin OWNER_NAME: your nickname on Github REPO_NAME: the name of your repo for your plugin on Github OWNER_EMAIL: an email for contact OWNER_REAL_NAME: your real name or not DESCRIPTION: description of your plugin falcoctl uses the keywords field to perform a search among your plugins. Leverage this functionality by adding relevant terms to your plugin.\nThe repository structure should look like the following:\n├── .github │ └── workflows │ └── release.yaml ├── .gitignore ├── go.mod ├── .goreleaser.yml ├── go.sum ├── index.yaml ├── LICENSE ├── Makefile ├── README.md ├── pkg │ └── {PLUGIN_NAME}.go ├── plugin │ └── main.go └── rules └── {PLUGIN_NAME}_rules.yaml There are 2 ways to expose the index.yaml file:\nexposing the raw file: https://raw.githubusercontent.com/{OWNER_NAME}/{REPO_NAME}/main/index.yaml exposing the file through Github Page: https://{OWNER_NAME}.github.io/{REPO_NAME}/index.yaml (make sure to enable the Pages) Create our first version Everything is now ready to publish a first version of our plugin.\nIn the main branch, run:\ngit tag 0.1.0 -m \u0026#34;0.1.0\u0026#34; \u0026amp;\u0026amp; git push origin 0.1.0 Few seconds after, your workflow should be started and you will have your first published version with associated artifacts.\nSee the results for the docker plugin:\nInstallation of your plugin and rules The process is now the same as the one described here, except we'll use your specific index.yaml to register a new index:\nsudo falcoctl index add {PLUGIN_NAME} https://{OWNER_NAME}.github.io/{REPO_NAME}/index.yaml sudo falcoctl artifact install {PLUGIN_NAME} sudo falcoctl artifact install {PLUGIN_NAME}-rules For the docker plugin, for example:\n❯ sudo falcoctl index add docker http://issif.github.io/docker-plugin/index.yaml ❯ sudo falcoctl artifact search docker INDEX ARTIFACT TYPE REGISTRY\tREPOSITORY docker\tdocker plugin ghcr.io issif/docker-plugin/plugin/docker docker\tdocker-rules\trulesfile\tghcr.io issif/docker-plugin/ruleset/docker ❯ sudo falcoctl artifact install docker-rules INFO Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; INFO Resolving dependencies ... INFO Installing the following artifacts: [docker:0.3.3 ghcr.io/issif/docker-plugin/ruleset/docker:latest] INFO Preparing to pull \u0026#34;ghcr.io/issif/docker-plugin/plugin/docker:0.3.3\u0026#34; INFO Pulling 9145239be00e: ############################################# 100% INFO Pulling 2073e106ba07: ############################################# 100% INFO Pulling 01ecf22a3821: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/usr/share/falco/plugins\u0026#34; INFO Preparing to pull \u0026#34;ghcr.io/issif/docker-plugin/ruleset/docker:latest\u0026#34; INFO Pulling 3482c7ca931f: ############################################# 100% INFO Pulling 433ad24cb056: ############################################# 100% INFO Pulling e449b880035d: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/etc/falco\u0026#34; Conclusion The last step is to promote your hard work to the community and have feedback about it. The whole process can be modified to match your own GitHub environment (private repo and registry), or even another platform with a little more work.\nYou can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or even for a friendly chat!\nIf you would like to find out more about Falco:\nGet started in Falco.org Plugin Documentation Plugin Developer Guide Plugin registry Check out the Falco project in GitHub Get involved in the Falco community Meet the maintainers on the Falco Slack Follow @falco_org on Twitter ","summary":"","tags":null,"title":"Extend Falco inputs by creating a Plugin: Distribute the plugin","url":"https://v0-43--falcosecurity.netlify.app/blog/extend-falco-inputs-with-a-plugin-distribute/"},{"category":"blog","content":"Introducing the brand-new eBPF probe: a game-changing addition to Falco's toolkit. Curious to learn more? Dive into our first blog post where we spill the beans on its exciting features, what you need to get started, and real-world use cases.\nInitially a Falco 0.34.0 experimental feature, we've put in months of hard work to refine it for production use. The wait is finally over! Falco 0.35.0 now ships with the modern probe as an official driver, alongside the trusted Kernel module and current eBPF probe. Falco is now more prepared than ever to scale with your infrastructure.\nSupported Syscalls In our driver history, we've supported syscalls in two possible ways:\nFully instrumented 🟢 Generically instrumented 🟡 Fully instrumented means that Falco notifies when a syscall is invoked in the system and enables the user to examine its parameters. You can find the list of available parameters for each syscall on https://falco.org/docs/reference/rules/supported-events/.\nGenerically instrumented means that Falco notifies when a syscall is invoked in the system, but nothing more.\nExcitingly, in the latest Falco 0.35.0 version, the modern probe extends its support to reach syscall parity with the other drivers. This report outlines the current instrumentation state.\nAdvanced support checks Before Falco 0.35.0, the modern probe was restricted to running exclusively on machines with kernel versions \u0026gt;= 5.8. This limitation posed challenges for certain users, prompting us to implement a more intelligent support detection mechanism. Leveraging the capabilities of the libbpf library, we can now search for specific features within the target system, precisely addressing our needs.\nTo elaborate further, we currently search for two crucial features that are essential for running the modern probe:\nBPF Ring Buffer BTF Tracing Programs For a more in-depth understanding of these two concepts, we invite you to explore the previous blog discussing the modern eBPF driver.\nNow, let's delve into the potential errors that you may encounter if any of these features are missing.\nIf the BPF ring buffer is not available, Falco will present you with an error message similar to:\nring buffer map type is not supported If BTF tracing programs are absent, the error message you can expect to encounter would be along the lines of:\ntracing program type is not supported Buffers allocation Every Falco driver utilizes shared buffers to facilitate the transmission of security events between the kernel and the userspace. To be more specific, there is an individual buffer allocated for each online CPU, ensuring efficient handling of events.\nWe have always followed this particular approach for utilizing shared buffers, and recently we introduced a new feature that allows you to modify the size of these buffers using a custom Falco configuration option called syscall_buf_size_preset. By default, each buffer is set to 8 MB, but you have the flexibility to adjust it anywhere between 1 MB and 512 MB.\nIncreasing the buffer size can be beneficial when you encounter syscall drops. A larger buffer size can help mitigate syscall drops in systems with high production loads. However, it's important to note that very large buffers may also impact the overall system performance, potentially slowing down the machine.\nConversely, reducing the buffer size can help enhance system speed, but it may also result in an increased number of syscall drops. It's crucial to exercise caution when experimenting with this configuration option, taking into consideration the trade-off between performance and syscall drops ⚠️\nWhile the ability to adjust buffer sizes is a cool feature, it is available to all drivers. So, what sets the modern probe apart? Well, with this new driver, you have the added capability to manipulate the number of buffers. This means that the traditional rule of having one buffer per CPU is no longer a strict requirement. Unlike the old drivers, where the only possible configuration was one buffer per CPU, the modern probe introduces flexibility in this aspect, opening up new possibilities and alternative scenarios.\nAs an illustration, one such scenario is the allocation of a ring buffer for every 3 CPUs.\nObserve that the second buffer can still be used by another CPU.\nTo adjust the number of buffers, you can use the Falco configuration option called modern_bpf.cpus_for_each_syscall_buffer. Unlike other drivers that have a 1:1 mapping between buffers and CPUs, the modern probe has a default value of one buffer for every two CPUs. This distinction arises because the BPF ring buffer requires more memory compared to other drivers, necessitating a reduction in the number of buffers.\nHowever, feel free to experiment and find the configuration that best suits your system. Just remember the following guideline: having more buffers can reduce the likelihood of drops but will increase the overall memory footprint. On the other hand, reducing the number of buffers can help decrease memory consumption but may lead to an increased risk of drops.\nLeast privileged mode Similar to the current probe, the modern probe can operate in least privileged mode. However, to ensure proper functionality, Falco always mandates a minimum of two capabilities: CAP_SYS_RESOURCE and CAP_SYS_PTRACE. Additional required capabilities vary depending on your specific kernel version, like the CAP_SYS_ADMIN capability for older kernels, which can be replaced by the CAP_PERFMON and CAP_BPF ones when running on a kernel newer than 5.8.\nHere's an example command to run Falco in least privileged mode using the modern probe:\ndocker run --rm -i -t \\ --cap-drop all \\ --cap-add sys_admin \\ --cap-add sys_resource \\ --cap-add sys_ptrace \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /proc:/host/proc:ro \\ falcosecurity/falco-no-driver:latest falco --modern-bpf Observe we cannot use CAP_BPF and CAP_PERFMON here since docker doesn't support them yet.\nTry it out The modern eBPF probe is compatible with all the installation methods available for other drivers.\nFalco packages Falco binary Docker Helm chart Also, you can test it live in this interactive environment that we have prepared for you.\nClick on it to start playing with it 🎮\n","summary":"","tags":["eBPF"],"title":"Modern eBPF probe is ready to shine","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-modern-bpf-0-35-0/"},{"category":"blog","content":"Dear Community, today we are delighted to announce the release of Falco 0.35.0!\nA big thank you to all our contributors for helping get the latest release out, we are thrilled to share this release and its goodies with the community. To read a detailed account of the release, see v0.35.0 in the changelog.\nDuring this release cycle, we had 90+ PRs on Falco and a grand total of 170+ PRs for libs 0.11.0 and 60+ for drivers 5.0.1. Thank you to our maintainers and contributors, as this would not happen without your support, dedication, and contribution!\nWhat's new? TL;DR 🩳 In release v0.35.0, we focused on addressing the following key features:\nMoving the modern eBPF probe out of experimental status Improving Falco performance, allowing tailoring syscall detection to one's needs New Falco metrics Falco images signing Improving plugins SDK Test infra revamp For more information check out the 0.35 overview video on YouTube\nModern eBPF probe 👨‍🚀 The new, modern eBPF probe was released as experimental during the 0.34.0 release cycle. Since then we worked hard to implement all the remaining syscalls and behaviors, and now the same eBPF probe has left experimental status.\nThe new eBPF probe is a CO-RE probe, which means it is already built into Falco, and you don't need any downloads. Moreover, it sports better performance compared to the old eBPF probe.\nFinally, while delivering the new eBPF probe, Andrea Terzolo also shipped a brand new driver testing framework, now used in libs CI to test consistency between all three drivers. This addition alone was worth the effort: on behalf of the whole community, thank you Andrea!\nThe new probe has stricter kernel release requirements: for more info, check out our blog post.\nImproved Falco performance Thanks to the collaborative effort from Melissa Kilby, Jason Dellaluce, Andrea Terzolo and Federico Di Pierro, we were able to completely revamp the way that Falco detects syscalls that needs to be captured. With the new adaptive syscalls feature, Falco will only enable syscalls that are needed to detect the ruleset it is being run with. It will also enable a bunch of syscalls that are needed for libsinsp internal state parsers, and that's it.\nConsequently, the -A flag semantics have changed. By default, ie. without -A, heavy syscalls (like I/O ones) won't be captured, even if the ruleset ships with them, and a warning is shown to the user. Using -A will now allow Falco to capture even heavy syscalls, without showing a warning. A couple of new config keys are now available to further tailor Falco adaptive syscalls: a related blog post will be published soon, so stay tuned!\nOne of the neatest things about this work is that the huge libs refactor it required lays the groundwork for another highly requested feature: LSM and kprobes support.\nFalco metrics Thanks to yet another collaborative effort led by Melissa, Falco has a new experimental metrics feature. This introduces a redesigned stats/metrics system, emitted as monotonic counters at predefined intervals (Prometheus-like).\nThere are multiple options available: one can enable the output of these metrics as internal metric snapshot rule, allowing them to be emitted as outputs. Or you can choose to output metrics to a file, that is not rotated by Falco. Moreover, there are options to enable CPU and memory usage metrics, internal kernel event counters and libbpf stats.\nThis is a great first step to improve Falco resource observability!\nFalco images signing Starting from 0.35.0, all Falco images that you can deploy in your cluster are now signed with cosign 2.0 in keyless mode.\nThis means that you can always verify that the Falco image you downloaded is an official Falco image, regardless of which registry you downloaded it from. Moreover, you don't have to install or explicitly trust any public key for it to work. This is the magic of cosign in action!\nSo, how do you verify our brand new images? Install cosign 2 and run:\ncosign verify docker.io/falcosecurity/falco:0.35.0 \\ --certificate-oidc-issuer=https://token.actions.githubusercontent.com \\ --certificate-identity-regexp=https://github.com/falcosecurity/falco/ \\ --certificate-github-workflow-ref=refs/tags/0.35.0 Of course, you can do the same for all the deployable images including falco, falco-driver-loader, falco-no-driver and falcoctl (see its repo for more details).\nThis wouldn't have been possible without a big effort from Luca Guerra and Federico Di Pierro to migrate our entire release pipeline from CircleCI to GitHub Actions. The work is part of a larger effort from the Falco Supply Chain Working Group to bring all the Falco official artifacts up to date with the latest supply chain security standards. Special thanks to Massimiliano Giovagnoli, Batuhan Apaydın and Carlos Panato for your help and expertise in this area!\nPlugins workstream The Plugin API has seen quite a few big improvements, mainly from Jason.\nThe first big change is that the plugin framework is now totally compatible with all the events supported by the Falco libraries, including all system calls and kernel events. The plugin API now shares all the event definitions of libscap and allows plugins to both produce syscall events and extract fields from them. This feature has been in big demand since the first plugin system release (#410, #992), and opens the door to many new opportunities for Falco extensions.\nSecond, plugins now have a standard way for managing and maintaining internal state. Up until now, plugins were only able to extract fields from the information available in the payloads of each event, thus being stateless components by definition. Now, plugins have a defined protocol (#991) for hooking into the event stream, reconstructing an internal state, and using it for extracting fields for Falco rules. Also, plugins can inject asynchronous metadata events in open data streams to notify about state transitions and make them reproduceable when replaying capture files, just like has always happened with container-related events in the Falco libraries.\nLastly, plugins are now able to communicate bidirectionally with the Falco libraries and access their internal state, both in read and write modes. For example, this enables creating plugins that extract metadata fields from syscall event streams, and that have access to all the thread information reconstructed by libsinsp, with the opportunity of enriching it dynamically at runtime. The API surface also allows cross-plugin state access. We hope the developer community will appreciate the new power this offers plugin authors.\nThis big feature package required altering the plugin API in a way that is incompatible with the previous versions (the API major version has been bumped). As such, plugins released after Falco version 0.35 will not be compatible with Falco versions \u0026lt;= 0.34.1, and plugins released before version 0.35 will not be compatible with Falco from version 0.35 onwards. So, the action required for you is to remember to also update all your plugins to the latest versions when updating Falco to v0.35!\nTest-infra revamp Massimiliamo Giovagnoli and Samuele Cappellin have contributed tremendous work on improving our infra. Prow is now lighter, quicker and less issue-prone. Multiple prow jobs were moved to GitHub Actions to improve cluster efficiency; moreover, driver-building jobs are now much less frequently killed (basically never).\nAlso, arm64 drivers are now built on arm64 nodes, without using qemu, speeding up the build time. At the same time, resources allocated to the cluster were enlarged, with autoscaling limits now set to 20 ARM nodes and 20 x86 nodes. We can now deliver weekly new driver artifacts much quicker than before!\nFinally, the cluster now exposes Grafana dashboards for monitoring purposes: https://monitoring.prow.falco.org/.\nTry it out It’s time to try out the new release! Here are some pointers for getting started with Falco:\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-no-driver (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package What next? 🔮 The community is active on many topics and we hope to deliver great features and many stability fixes once again during the next release cycle!\nWe will revisit and improve libsinsp API, for a more coherent developer experience. Finally, the long-awaited LSM and kprobes will be implemented. As the plugin API has seen huge improvements, we expect new plugins using the new features very soon. Fixes, fixes and also fixes everywhere Above all, we will work to improve thread tables and process trees inconsistencies; that's a huge topic and we plan to tackle it in multiple ways! Stay tuned 🤗 Join us in our communication channels and in our weekly community calls! It’s always great to have new members in the community, and we’re looking forward to having your feedback and hearing your ideas.\nYou can find all the most up to date information at https://falco.org/community/.\nSee you for the next release!\nFederico, Andrea and Lorenzo\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.35.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-35-0/"},{"category":"blog","content":" This blog post is an update of a post of November 2022\nAt the beginning of the year 2022, Falco introduced a game changing feature, the Falco Plugins. They allow Falco to monitor and trigger alerts for any kind of event. Since the launch of the new plugin framework the Falco community has collaborated to create plugins for Github, AWS CloudTrail and Okta. A plugin has also replaced the way Falco consumes the Audit Logs generated by a K8s API server through a dedicated plugin. With these plugins, Falco covers more in depth the aspects of your infrastructure and allows you to use a single syntax for rules.\nFor months (okay, maybe years...), our adopters have asked us for a way to monitor K8s Audit Logs. The previous implementation used an internal web server to receive the logs from the Kubernetes API, although it was functional, it was a very manual process to install and manage clusters. This method didn't support clusters managed by cloud providers, such as EKS, AKS, or GKE as they had to capture the Audit Logs for their own usage and then add them to their log aggregators.\nThis situation is now solved thanks to the plugin framework and we're proud to announce the first release of the plugin for EKS Audit Logs: k8saudit-eks!!!\nHow it works AWS captures the Audit Logs and exposes them in the CloudWatch Logs service. We have made available libs to create a clean session with the AWS API and pull logs from the relevant Cloudwatch Logs Stream. You can reuse these libs for any plugin you'd like to create for any Amazon service.\nUsage The configuration for the usage of the plugin is:\nplugins: - name: k8saudit-eks library_path: libk8saudit-eks.so init_config: region: \u0026#34;{REGION}\u0026#34; profile: \u0026#34;{AWS_PROFILE}\u0026#34; shift: 10 polling_interval: 10 use_async: false buffer_size: 500 open_params: \u0026#34;{CLUSTER_NAME}\u0026#34; - name: json library_path: libjson.so init_config: \u0026#34;\u0026#34; load_plugins: [k8saudit-eks, json] With:\ninit_config: profile: The Profile to use to create the session, env var AWS_PROFILE if present region: The Region of your EKS cluster, env var AWS_REGION is used if present use_async: If true then async extraction optimization is enabled (Default: true) polling_interval: Polling Interval in seconds (default: 5s) shift: Time shift in past in seconds (default: 1s) buffer_size: Buffer Size (default: 200) open_params: A string which contains the name of your EKS Cluster (required). If you run Falco inside an EKS cluster with a setup of an OIDC provider, the profile and region parameters can be omitted in favor of a service account + IAM Role (see the official docs).\nIAM Whatever the method you use for the authentication to the AWS API, you need to set up this minimal policy to your user/role:\n{ \u0026#34;Version\u0026#34;:\u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;:[ { \u0026#34;Sid\u0026#34;:\u0026#34;ReadAccessToCloudWatchLogs\u0026#34;, \u0026#34;Effect\u0026#34;:\u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;:[ \u0026#34;logs:Describe*\u0026#34;, \u0026#34;logs:FilterLogEvents\u0026#34;, \u0026#34;logs:Get*\u0026#34;, \u0026#34;logs:List*\u0026#34; ], \u0026#34;Resource\u0026#34;:[ \u0026#34;arn:aws:logs:${REGION}:${ACCOUNT_ID}:log-group:/aws/eks/${CLUSTER_NAME}/cluster:*\u0026#34; ] } ] } With:\nREGION: The Region of your EKS cluster ACCOUNT_ID: The ID of the account running the EKS cluster CLUSTER_NAME: The name of your cluster EKS cluster (same value than in your plugin configuration) Default Rules A good thing about Kubernetes is that it brings standards into our industry. Despite a few differences, the cluster works in the same way and produces the same format of logs. This helps us enormously. By creating the k8saudit plugin we declared the fields to extract, as well as some default rules, which we can reuse for any plugin that consumes the same Audit Logs. It is a time saver for both, developers and adopters.\nYou can find the proposed default rules here.\nInstallation For the installation, we'll use falcoctl. We can use it as a CLI tool for a locale installation or as a sidecar for Kubernetes. See this blog post for more information.\nLocal installation In this example, we'll see how to install the k8saudit-eks in a local host.\nFirst, add the index of artifacts for falcoctl:\nsudo falcoctl index add falcosecurity https://falcosecurity.github.io/falcoctl/index.yaml Install the latest version of the plugins:\nsudo falcoctl artifact install k8saudit-eks sudo falcoctl artifact install json As the output notices, the plugins will be now available in /usr/share/plugins:\nINFO Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; INFO Resolving dependencies ... INFO Installing the following artifacts: [ghcr.io/falcosecurity/plugins/plugin/k8saudit-eks:latest] INFO Preparing to pull \u0026#34;ghcr.io/falcosecurity/plugins/plugin/k8saudit-eks:latest\u0026#34; INFO Pulling b2daf90a878e: ############################################# 100% INFO Pulling 60b0846d1e18: ############################################# 100% INFO Pulling 12c7f0f5f00e: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/usr/share/plugins\u0026#34; INFO Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; INFO Resolving dependencies ... INFO Installing the following artifacts: [ghcr.io/falcosecurity/plugins/plugin/json:latest] INFO Preparing to pull \u0026#34;ghcr.io/falcosecurity/plugins/plugin/json:latest\u0026#34; INFO Pulling 087dba2e76d6: ############################################# 100% INFO Pulling c4cb35bb528a: ############################################# 100% INFO Pulling 9b50ea237bc6: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/usr/share/plugins\u0026#34; After installing the k8saudit-eks plugin, we also need to install the rules that it uses. (Those rules are the same as the k8saudit plugin rules.):\nsudo falcoctl artifact install k8saudit-rules --resolve-deps=false And we get the rules in /etc/falco:\nINFO Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; INFO Installing the following artifacts: [ghcr.io/falcosecurity/plugins/ruleset/k8saudit:latest] INFO Preparing to pull \u0026#34;ghcr.io/falcosecurity/plugins/ruleset/k8saudit:latest\u0026#34; INFO Pulling b8c6b1def3eb: ############################################# 100% INFO Pulling 6b6f3231f2b2: ############################################# 100% INFO Pulling 91b2b7a9944d: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/etc/falco\u0026#34; By default, the installation of a ruleset comes with the associated plugins. In this blog, we have installed them on our own, this is why --resolve-deps is set to false.\nWe now have the plugins and rules in our system. The last step is to configure Falco to use them. Modify your /etc/yaml to make it looks like the following (with the relevant values for REGION, ACCOUNT_ID, and CLUSTER_NAME):\nrules_files: ... - /etc/k8s_audit_rules.yaml plugins: - name: k8saudit-eks library_path: libk8saudit-eks.so init_config: region: \u0026#34;{REGION}\u0026#34; profile: \u0026#34;{AWS_PROFILE}\u0026#34; shift: 10 polling_interval: 10 use_async: false buffer_size: 500 open_params: \u0026#34;{CLUSTER_NAME}\u0026#34; - name: json library_path: libjson.so init_config: \u0026#34;\u0026#34; load_plugins: [\u0026#34;k8saudit-eks\u0026#34;,\u0026#34;json\u0026#34;] ... You can now start Falco ( sudo /usr/bin/falco --disable-source syscall) and monitor the audit logs of your EKS cluster:\nWed May 10 14:07:18 2023: Falco version: 0.34.1 (x86_64) Wed May 10 14:07:18 2023: Falco initialized with configuration file: /etc/yaml Wed May 10 14:07:18 2023: Loading plugin \u0026#39;k8saudit-eks\u0026#39; from file /usr/share/plugins/libk8saudit-eks.so Wed May 10 14:07:18 2023: Loading plugin \u0026#39;json\u0026#39; from file /usr/share/plugins/libjson.so Wed May 10 14:07:18 2023: Loading rules from file /etc/k8s_audit_rules.yaml Wed May 10 14:07:18 2023: Loading rules from file /etc/rules.d/override-k8saudit.yaml Wed May 10 14:07:18 2023: Starting health webserver with threadiness 4, listening on port 8765 Wed May 10 14:07:18 2023: Enabled event sources: k8s_audit Wed May 10 14:07:18 2023: Opening capture with plugin \u0026#39;k8saudit-eks\u0026#39; In this example, we also disable the collection of the syscalls with the option --disable-source syscall. The k8saudit-eks plugin works with a pull model, you should have only one Falco instance collecting the audit logs to avoid any duplication of alerts. We dedicate that instance to that role.\nAnd get alerts:\n14:09:17.699479000: Informational K8s Serviceaccount Created (user=system:node:ip-192-168-34-135.ec2.internal serviceaccount=default ns=default resource=serviceaccounts resp=201 decision=allow reason=) 14:09:24.046826000: Notice Attach/Exec to pod (user=kubernetes-admin pod=kubecon resource=pods ns=default action=exec command=sh) Kubernetes installation Next, we will see how to install the k8saudit-eks plugin with the falcoctl tool in a Kubernetes setup. We'll use the official Helm chart with the following values.yaml file:\nserviceAccount: create: true annotations: - eks.amazonaws.com/role-arn: {ROLE_ARN} falco: rules_files: - /etc/falco/k8s_audit_rules.yaml - /etc/falco/rules.d plugins: - name: k8saudit-eks library_path: libk8saudit-eks.so init_config: shift: 10 polling_interval: 10 use_async: false buffer_size: 500 open_params: \u0026#34;{CLUSTER_NAME}\u0026#34; - name: json library_path: libjson.so init_config: \u0026#34;\u0026#34; load_plugins: [k8saudit-eks, json] falcosidekick: enabled: true driver: enabled: false collectors: enabled: false controller: kind: deployment deployment: replicas: 1 falcoctl: indexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml artifact: install: enabled: true follow: enabled: true config: artifact: allowedTypes: - plugin - rulesfile install: resolveDeps: false refs: [k8saudit-rules:0, k8saudit-eks:0, json:0] follow: refs: [k8saudit-rules:0] Let's look into this configuration section by section:\nserviceAccount: create: true annotations: - eks.amazonaws.com/role-arn: {ROLE_ARN} With EKS, we can use an OIDC provider and annotations on the service accounts to allow access to the AWS API ( see the official docs). This section allows you to set which ROLE_ARN to use.\nfalco: rules_files: - /etc/falco/k8s_audit_rules.yaml - /etc/falco/rules.d plugins: - name: k8saudit-eks library_path: libk8saudit-eks.so init_config: shift: 10 polling_interval: 10 use_async: false buffer_size: 500 open_params: \u0026#34;{CLUSTER_NAME}\u0026#34; - name: json library_path: libjson.so init_config: \u0026#34;\u0026#34; load_plugins: [k8saudit-eks, json] As the local installation, this section sets the used plugins.\ndriver: enabled: false collectors: enabled: false controller: kind: deployment deployment: replicas: 1 To collect and monitor all the syscalls, Falco must be deployed as a DaemontSet in your cluster, to have one instance per Kernel. In this example, we're deploying Falco with the k8saudit-eks plugin, which relies on a pull model. To avoid several Falco pods to collect the same audit logs and duplicate the alerts, we MUST install Falco with the k8saudit-eks plugin only once. The Helm chart allows to use a one replica deployment and to disable the syscalls and K8s metdadata collections, this is the purpose of this section.\nfalcoctl: indexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml artifact: install: enabled: true follow: enabled: true config: artifact: allowedTypes: - plugin - rulesfile install: resolveDeps: false refs: [k8saudit-rules:0, k8saudit-eks:0, json:0] follow: refs: [k8saudit-rules:0] The last section sets up falcoctl. It will install the requested plugins and rules and track new versions of the rules.\nNow you can run your helm install command:\nhelm install falco-k8saudit-eks -n falco falcosecurity/falco -f ./values.yml And see the result:\n$ kubectl get pods -n falco NAME READY STATUS RESTARTS AGE falco-k8saudit-eks-96d7f6f99-vwjgc 2/2 Running 0 70m $ kubectl logs falco-k8saudit-eks-96d7f6f99-vwjgc -n falco -c falco Wed May 10 14:07:18 2023: Falco version: 0.34.1 (x86_64) Wed May 10 14:07:18 2023: Falco initialized with configuration file: /etc/falco/falco.yaml Wed May 10 14:07:18 2023: Loading plugin \u0026#39;k8saudit-eks\u0026#39; from file /usr/share/falco/plugins/libk8saudit-eks.so Wed May 10 14:07:18 2023: Loading plugin \u0026#39;json\u0026#39; from file /usr/share/falco/plugins/libjson.so Wed May 10 14:07:18 2023: Loading rules from file /etc/falco/k8s_audit_rules.yaml Wed May 10 14:07:18 2023: Loading rules from file /etc/falco/rules.d/override-k8saudit.yaml Wed May 10 14:07:18 2023: Starting health webserver with threadiness 4, listening on port 8765 Wed May 10 14:07:18 2023: Enabled event sources: k8s_audit Wed May 10 14:07:18 2023: Opening capture with plugin \u0026#39;k8saudit-eks\u0026#39; {\u0026#34;hostname\u0026#34;:\u0026#34;falco-k8saudit-eks-96d7f6f99-vwjgc\u0026#34;,\u0026#34;output\u0026#34;:\u0026#34;14:09:17.699479000: Informational K8s Serviceaccount Created (user=system:node:ip-192-168-34-135.ec2.internal serviceaccount=default ns=default resource=serviceaccounts resp=201 decision=allow reason=)\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Informational\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;K8s Serviceaccount Created\u0026#34;,\u0026#34;source\u0026#34;:\u0026#34;k8s_audit\u0026#34;,\u0026#34;tags\u0026#34;:[\u0026#34;k8s\u0026#34;],\u0026#34;time\u0026#34;:\u0026#34;2023-05-10T14:09:17.699479000Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;evt.time\u0026#34;:1683727757699479000,\u0026#34;ka.auth.decision\u0026#34;:\u0026#34;allow\u0026#34;,\u0026#34;ka.auth.reason\u0026#34;:\u0026#34;\u0026#34;,\u0026#34;ka.response.code\u0026#34;:\u0026#34;201\u0026#34;,\u0026#34;ka.target.name\u0026#34;:\u0026#34;default\u0026#34;,\u0026#34;ka.target.namespace\u0026#34;:\u0026#34;default\u0026#34;,\u0026#34;ka.target.resource\u0026#34;:\u0026#34;serviceaccounts\u0026#34;,\u0026#34;ka.user.name\u0026#34;:\u0026#34;system:node:ip-192-168-34-135.ec2.internal\u0026#34;}} {\u0026#34;hostname\u0026#34;:\u0026#34;falco-k8saudit-eks-96d7f6f99-vwjgc\u0026#34;,\u0026#34;output\u0026#34;:\u0026#34;14:09:24.046826000: Notice Attach/Exec to pod (user=kubernetes-admin pod=kubecon resource=pods ns=default action=exec command=sh)\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Notice\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Attach/Exec Pod\u0026#34;,\u0026#34;source\u0026#34;:\u0026#34;k8s_audit\u0026#34;,\u0026#34;tags\u0026#34;:[\u0026#34;k8s\u0026#34;],\u0026#34;time\u0026#34;:\u0026#34;2023-05-10T14:09:24.046826000Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;evt.time\u0026#34;:1683727764046826000,\u0026#34;ka.target.name\u0026#34;:\u0026#34;kubecon\u0026#34;,\u0026#34;ka.target.namespace\u0026#34;:\u0026#34;default\u0026#34;,\u0026#34;ka.target.resource\u0026#34;:\u0026#34;pods\u0026#34;,\u0026#34;ka.target.subresource\u0026#34;:\u0026#34;exec\u0026#34;,\u0026#34;ka.uri.param[command]\u0026#34;:\u0026#34;sh\u0026#34;,\u0026#34;ka.user.name\u0026#34;:\u0026#34;kubernetes-admin\u0026#34;}} Disclaimer Our tests noticed some latencies between the presence of the logs in the CloudWatch Logs Stream and their evaluation by Falco. This is more visible with highly requested API servers. The solution is to adapt the size of your nodes where Falco runs, considering a minimal size of 2xlarge as a safe option.\nConclusion With this first Plugin for a managed K8s solution, we hope to open the door for new contributions from the community for other flavors like GKE and AKS. If you need to create a plugin for another AWS service, take also a look at the libs we created to help the developers.\nYou can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or even for a friendly chat!\nIf you would like to find out more about Falco:\nGet started in Falco.org Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falco Plugins","Cloud"],"title":"Monitoring your EKS clusters audit logs","url":"https://v0-43--falcosecurity.netlify.app/blog/k8saudit-eks-plugin/"},{"category":"blog","content":"Falco rules management has been a discussed topic for quite a long time. When we start building and customizing rules for our environment, we need a simple way to effectively update and distribute them to our Falco fleet. Starting from Falco 0.34, we can easily do it by using OCI artifacts and leveraging any private or public container registry to store and retrieve them.\nBesides what OCI artifact are, in this blog we are going to learn 2 main concepts:\nHow we can create OCI artifacts containing our Falco rules in an automated way. How Falco can retrieve those OCI artifacts to update its local configuration: In a Linux server. In a Kubernetes cluster. As you can see, there's a lot of content to cover, so let's start right away.\nOCI artifacts OCI stands for Open Container Initiative, which is a project focused on creating open standards for container image formats and runtime specifications. An OCI artifact refers to a container image or a bundle that conforms to the OCI specifications.\nIn other words, our OCI artifacts will be similar to container images. They will be stored and made available by container registries. They could also be uploaded and downloaded using familiar tools in the container ecosystem.\nDoes it mean we need a container runtime to use it? Not at all.\nOCI artifacts for Falco are created using the falcoctl tool. This tool takes either a plain rules file or a set of them, inside a compressed file, and will, in a single step, create the OCI artifact and upload it to an OCI-complaint container registry.\nIn the node, where the falco daemon runs, falcoctl will retrieve that same OCI artifact, extract its content, and place it on the right place so falco can detect the latest threats.\nAutomating GitHub to pack Falco custom rules Rules management à la DevOps Git has become the de-facto technology to maintain a versioned copy of our most precious bits. Besides, it allows for automation and collaboration. These features makes it the perfect place to store our rules files. But what about distribution?\nUsing known CI/CD techniques we can pack the latest rules in a distributable object. Maybe we prefer to stick to a stable version, or maybe we want to be flexible offering multiple versions. Combining the power of Git with the standards of OCI, Falco is able to selectively retrieve the most suitable rules for each platform.\nChoose your weapons, here are mine Time to get our hands busy. We'll need for this tutorial:\nAn empty GitHub repo. A Falco ruleset file. A Falco installation. This tutorial will use both, Falco running as a systemd-service and also deployed using a Helm chart on Kubernetes. A container registry. We're going to use GitHub packages that comes with any public GitHub repository for free! And here is a high-level descriptions of the steps to follow:\nCreate an empty GitHub repo. Uploading our ruleset. A file is enough. Configuring GitHub Actions to generate and publish the OCI artifact. Testing. Not strictly required… just kidding. Always test. Simple enterprise, right? Then, let’s go for it.\nCreate a new GitHub repository That’s probably the easiest task here. We login to GitHub, go to repositories, and create that empty repo with the name of our like:\nUpload your Custom Ruleset Each person has their own liking for doing this step. Here, we'll clone the repo in a terminal, add the content, and commit it.\nDon’t forget to push the commit. It wouldn’t be the first time we hit our head against the wall for having forgotten it. Have I mention not to forget to push the commit.\nFor our example, we'll be creating a file named custom-falco-rules.yaml with the following content:\n- list: falco_binaries items: [falcoctl] It's not much, and it doesn't do much, we keep it simple, since the content of the rules files is not what we want to focus on. We'll update it later to something more useful for our example.\nIt's time to upload it to the repository:\n$ git clone https://github.com/vjjmiras/cool-falco-rules $ cp /tmp/custom_falco_rules.yaml ./cool-falco-rules/ $ cd cool-falco-rules $ git add custom_falco_rules.yaml $ git commit -s -m \u0026#39;first iteration of my cool falco rules\u0026#39; And that’s it. Now we have some content ready for the next step. That was probably no challenge for many of you.\nConfiguring GitHub Actions Well, that’s going to be the fun part. Basically, we’ll tell GitHub what to do when a new version of the ruleset file is pushed to the repository.\nAgain, a high-level description of the steps to follow will surely help:\nDownload the Falcoctl tool. Retrieve content of the rules repository (the file we want to distribute as an OCI artifact). Upload the OCI artifact to the container registry. You might be wondering whether we forgot any step. We surely did, intentionally. Just some little tasks that’ll help us set up the workflow properly. What we haven’t missed is the step to convert the ruleset file into an OCI artifact. That’s falcoctl job.\nNow, let’s create an outline for the workflow.\nFeel free to jump to the resulting workflow file. You can always come back here to see through the process of creating it.\n$ mkdir -p .github/workflows/ $ vim .github/workflows/release.yaml --- name: Release Rulesfile on: push jobs: Release-Rulesfile: runs-on: ubuntu-latest steps: - name: step 1 ... - name: step 2 ... To add some flexibility to our example, we'll add a few environmental variables that can be easily tuned for experimentation. These will be the name of the rules file, the container registry that'll store the artifact, and the name and version of it.\njobs: Release-Rulesfile: ... env: # Only one ruleset file for our demo RULESET_FILE: custom_falco_rules.yaml # Used to setup Auth and OCI artifact location OCI_REGISTRY: ghcr.io # Assuming we are in the main branch, our OCI artifact will # look something like ghcr.io/user/repo/custom-rules:main OCI_ARTIFACT_NAME: custom-rules OCI_ARTIFACT_VERSION: ${{ github.ref_name }} steps: ... Since we need to upload the OCI Artifact to the container registry, let's grant our workflow write permisions that'll allow us to use the GitHub token for that purpose.\nBe aware that we are using the GitHub container registry. You wouldn't need those permissions here if you happened to use an external one.\njobs: Release-Rulesfile: ... # These permissions are needed to interact with GitHub\u0026#39;s OIDC Token endpoint. permissions: id-token: write contents: read packages: write env: ... steps: ... Time to add the steps to our workflow to let falcoctl tool create the OCI artifact with out rules.\nDefine the Steps in your Workflow The next 3 tasks have one simple goal: Build the falcoctl tool. We mentioned before we were going to download it, but at the time of writing this, the latest released version wasn't supporting registry authentication properly. That's our main reason to compile it here.\nFalcoctl tool Let's start with downloading the source code for our tool to the ./tools/falcoctl directory. We'll need that path to access falcoctl later.\n- name: Checkout Falcoctl Repo uses: actions/checkout@v3 with: repository: falcosecurity/falcoctl ref: main path: tools/falcoctl The second task is just an auxiliary task that will enable the Go cache, which might not be necessary, but it'll save us a lot of time every time you compile the falcoctl tool.\nFeel free to ignore the following step it at your discretion, although I wouldn't recommend it.\n- name: Setup Golang uses: actions/setup-go@v4 with: go-version: \u0026#39;^1.20\u0026#39; cache-dependency-path: tools/falcoctl/go.sum Pay attention to the parameter (last line) passed to cache the dependencies. It'll depend on the values set in the previous task.\nFinally, a simple build step and our tool will be available as ./tools/falcoctl/falcoctl\n- name: Build falcoctl run: make working-directory: tools/falcoctl One last step before creating and uploading the OCI artifact is to have the rules we are pushing into it. This simple GitHub Action will download our repo into the rules/ directory.\n- name: Checkout Rules Repo uses: actions/checkout@v3 with: path: rules Upload the OCI Artifact Here it is where the magic happens. This example spreads across multiple lines to make it easier to understand.\n1| - name: Upload OCI artifacts to GitHub packages 2| run: | 3| tools/falcoctl/falcoctl registry push \\ 4| --config /dev/null \\ 5| --type rulesfile \\ 6| --version ${OCI_ARTIFACT_VERSION} \\ 7| ${OCI_REGISTRY}/${GITHUB_REPOSITORY}/${OCI_ARTIFACT_NAME}:${OCI_ARTIFACT_VERSION} \\ 8| rules/${RULESET_FILE} The systax will look like: falcoctl registry push [--option ...] destination-url source-file. Let's dissect the command for a better understanding.\nLine 2, uses the | symbol, which indicates that all the segments at the same indentation level will be interpreted as a single line. YAML specifics. Line 3, contains the cli verbs, the fresly compiled falcoctl tool with the subverbs registry push as shown above. The options will come later. Line 4, --config /dev/null, is required to tell falcoctl not to use a configuration file. Otherwise it will try to create the directory /etc/falcoctl and we might not have permissions for that. Using a config file is an alternative, but for simplicity and pedagogical reasons we've kept everything on the command line. Line 5, --type rulesfile, indicates what time of content should this artifact have. It could be a plugin or a rulesfile Line 6, --version ${OCI_ARTIFACT_VERSION}, indicates the version of the artifact. It might look a bit redundant, but it's a mandatory option for the falcoctl command. Line 7 is the destination URL to push the OCI artifact into. It should contain the registry, git user and repo name, name of the artifact, and the tag, which we have called version in this blog post. Line 8 is just the name of the rulesfile that the OCI artifact will include. Credentials Our step won't need any previous authentication step thanks to the environment variable FALCOCTL_REGISTRY_AUTH_BASIC that we'll add at the end of the last step. This variable can contain any number of credentials separated by a semi-colon, but we require only one in our example.\nThe 3 elements of a credential, separated by commas, are the registry url, the user that is authenticating and the token for that user.\nAppended to the step where we were pushing the OCI artifact, and based on environmental information, we'll instantiate the variable as:\nenv: FALCOCTL_REGISTRY_AUTH_BASIC: ${{ env.OCI_REGISTRY }},${{ github.repository_owner }},${{ secrets.GITHUB_TOKEN }} Final Workflow File Once our workflow is complete, it should look like:\n--- name: Release Rulesfile on: push jobs: Release-Rulesfile: runs-on: ubuntu-latest # These permissions are needed to interact with GitHub\u0026#39;s OIDC Token endpoint. permissions: id-token: write contents: read packages: write env: # Only one ruleset file for our demo RULESET_FILE: custom_falco_rules.yaml # Used to setup Auth and OCI artifact location OCI_REGISTRY: ghcr.io # Assuming we are in the main branch, our OCI artifact will # look something like ghcr.io/user/repo/custom-rules:main OCI_ARTIFACT_NAME: custom-rules OCI_ARTIFACT_VERSION: ${{ github.ref_name }} steps: - name: Checkout Falcoctl Repo uses: actions/checkout@v3 with: repository: falcosecurity/falcoctl ref: main path: tools/falcoctl - name: Setup Golang uses: actions/setup-go@v4 with: go-version: \u0026#39;^1.20\u0026#39; cache-dependency-path: tools/falcoctl/go.sum - name: Build falcoctl run: make working-directory: tools/falcoctl - name: Checkout Rules Repo uses: actions/checkout@v3 with: path: rules - name: Upload OCI artifacts to GitHub packages run: | tools/falcoctl/falcoctl registry push \\ --config /dev/null \\ --type rulesfile \\ --version ${OCI_ARTIFACT_VERSION} \\ ${OCI_REGISTRY}/${GITHUB_REPOSITORY}/${OCI_ARTIFACT_NAME}:${OCI_ARTIFACT_VERSION} \\ rules/${RULESET_FILE} env: FALCOCTL_REGISTRY_AUTH_BASIC: ${{ env.OCI_REGISTRY }},${{ github.repository_owner }},${{ secrets.GITHUB_TOKEN }} Once the file is ready, we'll upload it to GitHub, where it'll be processed by GitHub Actions. After that, we'll just need to wait for the workflow to finish.\n$ git add .github/workflows/ $ git commit -s -m \u0026#39;new: GitHub Actions added to the repo\u0026#39; $ git push -u origin main Your repository will probably look like this:\nAnd if your GitHub action executed successfully, it'll look like this:\nNow it's time to test our freshly generated OCI artifact.\nTesting our Rules Workflow How do we test our new fancy rule distribution system? The best way would be using a customizable Falco installation to pull our rules.\nHere we can have two scenarios: running Falco as a Linux service or deploying it as a Kubernetes Daemonset. Let's cover both of them to see the differences.\nFalco and Falcoctl running as Linux services For this scenario, I'll use the Try Falco scenario which instructions are available in the Falco website. Only the first set of instructions are required to have the scenario up and running. Once our scenario is ready, we'll proceed to configure the rules automatic update.\nFirst of all, let's have a look into the falcoctl-artifact-follow.service unit status:\n$ sudo systemctl status falcoctl-artifact-follow.service ● falcoctl-artifact-follow.service - Falcoctl Artifact Follow: automatic artifacts update service Loaded: loaded (/lib/systemd/system/falcoctl-artifact-follow.service; disabled; vendor preset: enabled) Active: active (running) since Wed 2023-04-12 15:34:06 UTC; 55s ago Docs: https://falco.org/docs/ Main PID: 16152 (falcoctl) Tasks: 8 (limit: 2271) Memory: 10.5M CGroup: /system.slice/falcoctl-artifact-follow.service └─16152 /usr/bin/falcoctl artifact follow --allowed-types=rulesfile Apr 12 15:34:06 vagrant systemd[1]: Started Falcoctl Artifact Follow: automatic artifacts update service. Apr 12 15:34:06 vagrant falcoctl[16152]: INFO: Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; Apr 12 15:34:06 vagrant falcoctl[16152]: WARN: No configured index. Consider to configure one using the \u0026#39;index add\u0026#39; command. Apr 12 15:34:06 vagrant falcoctl[16152]: INFO: Creating follower for \u0026#34;falco-rules:0\u0026#34;, with check every 6h0m0s Apr 12 15:34:07 vagrant falcoctl[16152]: INFO Starting follower for \u0026#34;ghcr.io/falcosecurity/rules/falco-rules:0\u0026#34; Apr 12 15:34:07 vagrant falcoctl[16152]: INFO (ghcr.io/falcosecurity/rules/falco-rules:0) found new version under tag \u0026#34;0\u0026#34; Apr 12 15:34:10 vagrant falcoctl[16152]: INFO (ghcr.io/falcosecurity/rules/falco-rules:0) artifact with tag \u0026#34;0\u0026#34; correctly installed vagrant@vagrant:~$ We can see there that there is an instance of falcoctl following an item named falco-rules:0. We'll come back to that later.\nLet's have a look then into falcoctl.yaml configuration file, the default one, since no other explicit configuration file has been passed for the service.\n$ cat /etc/falcoctl/falcoctl.yaml artifact: follow: every: 6h0m0s falcoVersions: http://localhost:8765/versions refs: - falco-rules:0 indexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml All right, that is lot of useful information. Let's take our time. First, we can observe it contains 2 configuration sections, artifact and indexes.\nThe artifact section instructs falcoctl to update the rules files when necessary, checking for updates every 6 hours. The files to be updated are referenced under the refs: section. That list contains a single element at the moment: falco-rules:0. That should ring a bell, right?\nNow, to understand what falco-rules:0 means, we should look into the indexes section. An index is a file describing where to download an OCI artifact from, and what to do with it. At the moment, it only supports passing the file via http. However, using a local file will also be an option in the future.\nIn the following command, we'll extract the 14 lines that are relevant to to the falco-rules artifact:\n$ curl -s https://falcosecurity.github.io/falcoctl/index.yaml | \\ grep --after-context=13 -- \u0026#34;^- name: falco-rules\u0026#34; - name: falco-rules type: rulesfile registry: ghcr.io repository: falcosecurity/rules/falco-rules description: Falco rules that are loaded by default home: https://github.com/falcosecurity/rules/blob/main/rules/falco_rules.yaml keywords: - falco-rules license: apache-2.0 maintainers: - email: cncf-falco-dev@lists.cncf.io name: The Falco Authors sources: - https://github.com/falcosecurity/rules/blob/main/rules/falco_rules.yaml We can see in that index the locations of the different OCI artifacts containing each one of the rules files. That in particular is the entry of the falco-rules artifact. However, we see no trace of that :0 suffix.\nLet's use the command falcoctl artifact info to see where that takes us. That command will use the index file and will share information obtained from the remote artifact.\n$ falcoctl artifact info falco-rules REF TAGS ghcr.io/falcosecurity/rules/falco-rules\tlatest, 0.1.0, 0.1, 0, 0.1.0-rc1 We found it! The :0 suffix is just a floating tag referring, in our example, to the 0.1.0 tag. Falco could have used the 0.1.0 tag directly, the 0.1 one, or even the :latest tag (but that could have had some consequences in the future).\nSummarizing what we have learned so far:\nfalcoctl will follow the artifact tagged as falco-rules:0 which resolves to the OCI artifact ghcr.io/falcosecurity/rules/falco-rules:0.1.0. This information results from combining the /etc/falcoctl/falcoctl.yaml configuration file and the https://falcosecurity.github.io/falcoctl/index.yaml index file. The OCI artifact ghcr.io/falcosecurity/rules/falco-rules:0 could point to a different artifact in the future without us having to reconfigure every Falco installation. Every 6 hours, falcoctl will check whether the artifact has changed and will update it locally. Customize Falcoctl configuration To let falcoctl manage our new artifacts, we are going to add some changes to our falcoctl.yaml configuration.\nFirst, we are installing new custom rules, so we'll add that to the artifact.install section:\nartifact: ... install: refs: - ghcr.io/vjjmiras/cool-falco-rules/custom-rules:main Then, let's add the new artifact to follow and decrease the checking interval to 5 minutes:\nartifact: follow: every: 5m0s ... refs: - falco-rules:0 - ghcr.io/vjjmiras/cool-falco-rules/custom-rules:main If you container registry is private and requires credentials to access it, here you can find further information to configure it: Falcoctl Configuration Example.\nThe final falcoctl.yaml file would look like that, depending on the changes you have done:\n$ cat /etc/falcoctl/falcoctl.yaml artifact: follow: every: 5m0s falcoVersions: http://localhost:8765/versions refs: - falco-rules:0 - ghcr.io/vjjmiras/cool-falco-rules/custom-rules:main indexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml To verify the custom_falco_rules.yaml file doesn't exist, we'll\n$ stat /etc/falco/custom_falco_rules.yaml stat: cannot access \u0026#39;/etc/falco/custom_falco_rules.yaml\u0026#39;: No such file or directory Before we fully apply those changes, instruct Falco to read this new file. Open the file /etc/falco/falco.yaml and add the new rules file:\n... rules_files: - /etc/falco/falco_rules.yaml - /etc/falco/falco_rules.local.yaml - /etc/falco/custom_falco_rules.yaml \u0026lt;-- Add this line - /etc/falco/rules.d Time to let falcoctl follow the new artifact:\n$ sudo systemctl restart falcoctl-artifact-follow $ sudo systemctl status falcoctl-artifact-follow $ sudo cat /etc/falco/custom_falco_rules.yaml - list: falco_binaries items: [falcoctl] Before we move on, observe the alert that Falco has been giving when the falcoctl-artifact-follow service restarts:\n$ sudo systemctl status falco ... Apr 14 15:31:19 vagrant falco[24944]: 15:31:19.049935845: Error File below /etc opened for writing (user=root user_loginuid=-1 command=falcoctl artifact follow --allowed-types=rulesfile pid=24990 parent=falcoctl pcmdline=falcoctl artifact follow --allowed-types=rulesfile file=/etc/falco/._check_writable program=falcoctl gparent=\u0026lt;NA\u0026gt; ggparent=\u0026lt;NA\u0026gt; gggparent=\u0026lt;NA\u0026gt; container_id=host image=\u0026lt;NA\u0026gt;) ... We can get rid of that alert by extending our custom-falco-rules.yaml ruleset file, generate a new OCI artifact and let falcoctl download it. It'll be the perfect example to test our new configuration.\nThe following macro adds a new condition not to trigger the rule. The condition is that the process trying to write in the the /etc/ directory is falcoctl. We added that list previously to have some content in the file.\n- list: falco_binaries items: [falcoctl] - macro: write_etc_common append: true condition: and not proc.pname in (falco_binaries) $ git commit -a -s -m \u0026#39;new: adding the macro to the list\u0026#39; [main b82c5e6] adding the macro to the list 1 file changed, 4 insertions(+) $ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 12 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 439 bytes | 219.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/vjjmiras/cool-falco-rules.git 957bbcc..b82c5e6 main -\u0026gt; main This should trigger the GitHub actions workflow and in a few minutes, we should have an updated ruleset file in our /etc/falco directory:\n$ sudo cat /etc/falco/custom_falco_rules.yaml - list: falco_binaries items: [falcoctl] - macro: write_etc_common append: true condition: and not proc.pname in (falco_binaries) If you look at the status of the falco service you should see the line indicating the reload of Falco's configuration:\nfalco[...]: SIGHUP received, restarting... Falco and Falcoctl running on Kubernetes The architecture here is a bit different. Basically, since falco is deployed as a container inside a Pod managed by a DaemonSet, falcoctl will also run as a sidecar container within the same Pod. That way, they can share the rules directory where falcoctl will deposit every updated version of the rules files.\nLet's start deploying Falco on Kubernetes and see how the initial configuration looks like:\n$ helm install falco -n falco --set tty=true falcosecurity/falco NAME: falco LAST DEPLOYED: Fri Apr 14 16:37:19 2023 NAMESPACE: falco STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Falco agents are spinning up on each node in your cluster. After a few seconds, they are going to start monitoring your containers looking for security issues. $ kubectl -n falco get daemonset,pods NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/falco 1 1 1 1 1 \u0026lt;none\u0026gt; 81s NAME READY STATUS RESTARTS AGE pod/falco-8dv99 2/2 Running 0 81s There we can see the falco Pod with 2 running containers. Let's extract their names:\n$ kubectl -n falco get pod falco-8dv99 -o jsonpath=\u0026#39;{range .spec.containers[*]}{.name}{\u0026#34;\\t\u0026#34;}{.spec.containers[*]}{.image}{\u0026#34;\\n\u0026#34;}{end}\u0026#39; falco docker.io/falcosecurity/falco-no-driver:0.34.1 falcoctl-artifact-follow docker.io/falcosecurity/falcoctl:0.4.0 The first container seems to be based on the falco-no-driver image (the driver is loaded separately), and the second one has the name falcoctl-artifact-follow. If you went through the previous section, you'll see the name of the container matches the service name in Linux.\nNow we need to look for the configuration file. We saw in the previous section its name was /etc/falcoctl/falcoctl.yaml. Let's start extracting the volumes on the falcoctl-artifact-follow container:\n$ kubectl -n falco get pod falco-8dv99 -o json | jq \u0026#39;.spec.volumes[]\u0026#39; [ ... output omitted ... { \u0026#34;configMap\u0026#34;: { \u0026#34;defaultMode\u0026#34;: 420, \u0026#34;items\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;falcoctl.yaml\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;falcoctl.yaml\u0026#34; } ], \u0026#34;name\u0026#34;: \u0026#34;falco-falcoctl\u0026#34; }, } ... output omitted ... ] Now that we have the configMap name, we can proceed to update its configuration.\nCustoming the Falcoctl ConfigMap It is a good practice to observe what normal logs look like before changing a program to a newer configuration. So just to keep track of it:\n$ kubectl -n falco logs falco-8dv99 -c falcoctl-artifact-follow INFO: Retrieving versions from Falco (timeout 2m0s) ... INFO: Successfully retrieved versions from Falco ... INFO: Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; WARN: No configured index. Consider to configure one using the \u0026#39;index add\u0026#39; command. INFO: Creating follower for \u0026#34;falco-rules:0\u0026#34;, with check every 6h0m0s ... output omitted... Nothing new, it follows the falco-rules:0 artifact and checks every 6 hours. Same as in the previous section.\nHere we have the default configuration installed by Helm when deploying falco and falcoctl:\n$ kubectl -n falco get cm falco-falcoctl -o yaml ... output omitted ... data: falcoctl.yaml: |- artifact: allowedTypes: - rulesfile follow: every: 6h falcoversions: http://localhost:8765/versions pluginsDir: /plugins refs: - falco-rules:0 rulesfilesDir: /rulesfiles install: pluginsDir: /plugins refs: - falco-rules:0 resolveDeps: false rulesfilesDir: /rulesfiles indexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml ... output omitted ... and here are the changes that we want to do on it so it checks every 2 minutes, as before, and for a newer OCI artifact.\n... artifact: ... follow: every: 2m refs: - ghcr.io/vjjmiras/cool-falco-rules/custom-rules:main ... Translated into our Helm chart values.yaml, the fields to modify would look like:\n... falcoctl: ... config: ... artifact: ... install: refs: - falco-rules:0 - ghcr.io/vjjmiras/cool-falco-rules/custom-rules:main \u0026lt;-- Add this line ... follow: refs: - falco-rules:0 - ghcr.io/vjjmiras/cool-falco-rules/custom-rules:main \u0026lt;-- Add this line every: 2m \u0026lt;-- Modify this line ... The previous and following steps assume you have a local values.yaml file that you can customize. We'll pass it as an argument (-f option) to the Helm command updating in this way our Falco deployment.\nYou can download a copy of that file from here.\nFollowed by Helm upgrade command:\n$ helm upgrade falco -n falco --set tty=true -f values.yaml falcosecurity/falco Once we have updated those changes, we can wait for the new Pods with the current configuration:\n$ kubectl -n falco get pods -w NAME READY STATUS RESTARTS AGE falco-np6hj 0/2 Init:1/2 0 4s falco-np6hj 0/2 PodInitializing 0 6s falco-np6hj 1/2 Running 0 7s falco-np6hj 2/2 Running 0 45s Once the Pod is running, the logs from the sidecar container should tell us if all went as expected:\n$ kubectl -n falco logs falco-np6hj -c falcoctl-artifact-follow INFO: Retrieving versions from Falco (timeout 2m0s) ... INFO: Successfully retrieved versions from Falco ... INFO: Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; WARN: No configured index. Consider to configure one using the \u0026#39;index add\u0026#39; command. INFO: Creating follower for \u0026#34;ghcr.io/vjjmiras/cool-falco-rules/custom-rules:main\u0026#34;, with check every 2m0s Our rules artifact is being followed now, it'll check every 2 minutes, so we can observe the content of the rules directory and the rules file:\n$ kubectl -n falco exec falco-np6hj -c falco -it -- ls -l /etc/falco/ -rw------- 1 root root 43 Apr 14 17:11 custom_falco_rules.yaml -rw-r--r-- 1 root root 1626 Apr 14 17:11 falco.yaml -rw-r--r-- 1 root root 147885 Apr 14 17:11 falco_rules.yaml $ kubectl -n falco exec falco-np6hj -c falco -it -- cat /etc/falco/custom_falco_rules.yaml - list: falco_binaries items: [falcoctl] To test the workflow, as we did before, we can update the rules file locally, commit and push it to GitHub, and see if falcoctl updates it the same way it did in the previous section.\nAfter some minutes, this should be the content of the rules file inside the new container:\n$ kubectl -n falco exec falco-np6hj -c falco -it -- \\ cat /etc/falco/custom_falco_rules.yaml - list: falco_binaries items: [falcoctl] - macro: write_etc_common append: true condition: and not proc.pname in (falco_binaries) To make falco use this file, we'd need to tell Falco where to find these new rules. We can do that by editing the Helm values.yaml file again to make Falco aware of our custom rules file:\nfalco: ... rules_files: - /etc/falco/falco_rules.yaml - /etc/falco/falco_rules.local.yaml - /etc/falco/custom_falco_rules.yaml \u0026lt;-- Add this line - /etc/falco/rules.d Followed again by the respective Helm upgrade command:\n$ helm upgrade falco -n falco --set tty=true -f values.yaml falcosecurity/falco Once updated the deployment, we can wait for the Pods with the newest configuration. Their logs will look like the following:\n$ kubectl -n falco logs falco-np6hj -c falco Fri Apr 14 17:24:20 2023: Falco version: 0.34.1 (x86_64) Fri Apr 14 17:24:20 2023: Falco initialized with configuration file: /etc/falco/falco.yaml Fri Apr 14 17:24:20 2023: Loading rules from file /etc/falco/falco_rules.yaml Fri Apr 14 17:24:20 2023: Loading rules from file /etc/falco/custom_falco_rules.yaml ... output omitted ... And we can continue updating our rules files in the GitHub repository, the GitHub Actions pipeline will take care of creating the OCI artifacts, and falcoctl will distribute those rules to wherever we have configured.\nConclusion The Falco community has recognized the importance of staying up-to-date with the latest security threats and best practices, and the Falco maintainers have adopted the use of OCI artifacts as a solution for easy, controlled, and efficient delivery of Falco rules.\nThrough this blog, readers have learned how using OCI artifacts Falco takes a step towards ensuring the security of their systems and staying ahead of potential security threats.\n","summary":"","tags":["Rules","Falcoctl"],"title":"GitOps your Falco Rules","url":"https://v0-43--falcosecurity.netlify.app/blog/gitops-your-falco-rules/"},{"category":"blog","content":"Hi everyone!\nToday we are going to learn how to add support for a new distro prebuilt drivers.\nThere are multiple repositories involved with it, and while most of the time it should be a pretty simple job, other times it can become really cumbersome.\nThat's why we are writing this guide of course!\nThe involved repositories will be:\nKernel-crawler Driverkit Falco Test-infra Kernel-crawler NOTE: this step is only needed if kernel-crawler does not already support the distro.\nKernel-crawler is a python project that is capable of fetching all existing kernels by scraping multiple distros repositories.\nIt is ran weekly each Monday at 6.30am UTC, by a github action, to update the jsons for all supported architectures (at the moment of writing x86_64 and aarch64) by opening a PR on same kernel-crawler against the kernels branch.\nThe kernels branch is also used as a source for the github pages.\nIn the end, the project code lives in the main branch, while the jsons and the github page live under the kernels branch.\nFirst of all, you want to add a scraper for the new distro to kernel-crawler.\nLet's see for example the archlinux one:\nfrom bs4 import BeautifulSoup import re from kernel_crawler.utils.download import get_url from . import repo class ArchLinuxRepository(repo.Repository): _linux_headers_pattern = \u0026#39;linux.*headers-\u0026#39; _package_suffix_pattern = \u0026#39;.pkg.tar.*\u0026#39; def __init__(self, base_url, arch): self.base_url = base_url self.arch = arch def __str__(self): return self.base_url def parse_kernel_release(self, kernel_package): # trim off \u0026#39;linux*headers\u0026#39; trimmed = re.sub(self._linux_headers_pattern, \u0026#39;\u0026#39;, kernel_package) # trim off the \u0026#39;.pkg.tar.*\u0026#39; version_with_arch = re.sub(self._package_suffix_pattern, \u0026#39;\u0026#39;, trimmed) # trim off the architecture version = re.sub(f\u0026#39;-{self.arch}\u0026#39;, \u0026#39;\u0026#39;, version_with_arch) return version def get_package_tree(self, filter=\u0026#39;\u0026#39;): packages = {} soup = BeautifulSoup(get_url(self.base_url), features=\u0026#39;lxml\u0026#39;) for a in soup.find_all(\u0026#39;a\u0026#39;, href=True): package = a[\u0026#39;href\u0026#39;] # skip .sig and .. links if not package.endswith(\u0026#39;.sig\u0026#39;) and package != \u0026#39;../\u0026#39;: parsed_kernel_release = self.parse_kernel_release(package) packages.setdefault(parsed_kernel_release, set()).add(self.base_url + package) return packages class ArchLinuxMirror(repo.Distro): _base_urls = [] def __init__(self, arch): if arch == \u0026#39;x86_64\u0026#39;: self._base_urls.append(\u0026#39;https://archive.archlinux.org/packages/l/linux-headers/\u0026#39;) # stable self._base_urls.append(\u0026#39;https://archive.archlinux.org/packages/l/linux-hardened-headers/\u0026#39;) # hardened self._base_urls.append(\u0026#39;https://archive.archlinux.org/packages/l/linux-lts-headers/\u0026#39;) # lts self._base_urls.append(\u0026#39;https://archive.archlinux.org/packages/l/linux-zen-headers/\u0026#39;) # zen elif arch == \u0026#39;aarch64\u0026#39;: self._base_urls.append(\u0026#39;http://tardis.tiny-vps.com/aarm/packages/l/linux-aarch64-headers/\u0026#39;) # arm 64-bit else: # can be implemented later self._base_urls.append(\u0026#39;http://tardis.tiny-vps.com/aarm/packages/l/linux-armv5-headers/\u0026#39;) # arm v5 self._base_urls.append(\u0026#39;http://tardis.tiny-vps.com/aarm/packages/l/linux-armv7-headers/\u0026#39;) # arm v7 self._base_urls.append(\u0026#39;http://tardis.tiny-vps.com/aarm/packages/l/linux-raspberrypi4-headers/\u0026#39;) # rpi4 self._base_urls.append(\u0026#39;http://tardis.tiny-vps.com/aarm/packages/l/linux-raspberrypi-headers/\u0026#39;) # other rpi super(ArchLinuxMirror, self).__init__(self._base_urls, arch) def list_repos(self): mirrors = [] for mirror in self._base_urls: mirrors.append(ArchLinuxRepository(mirror, self.arch)) return mirrors def to_driverkit_config(self, release, deps): for dep in deps: return repo.DriverKitConfig(release, \u0026#34;arch\u0026#34;, dep) As you can see, the ArchlinuxMirror extends repo.Distro and implements the list_repos and to_driverkit_config methods.\nThe former is called by get_package_tree while discovering the list of supported kernels to fetch all the available repos, while the latter is an adapter used to output the json in a driverkit-like format, that is the format spoken by test-infra dbg scripts (aka Driverkit Build Grid). ArchlinuxRepository class implements the repository scraping logic: basically, for each repository, its package tree is fetched and kernel versions are filtered.\nThen, the to_driverkit_config method should return a list of repo.DriverKitConfig.\nIt is important that the second parameter to DriverKitConfig is the distro target name as extracted by:\ngrep ID /etc/os-release | head -n1 When using /etc/os-release is not possible (eg: for the minikube scraper it wasn't), you'll probably need to update the logic in falco-driver-loader script too; we will see that later in the falco-driver-loader step.\nFinally, you need to register the new distro together with its mirror in the kernel_crawler/crawler.py source file, following what is being done for other entries:\nDISTROS = { ... // other entries \u0026#39;ArchLinux\u0026#39;: ArchLinuxMirror, ... // other entries } Time to test the changes! From the repository root, run:\npython -m kernel_crawler.main crawl --distro ArchLinux If everything is fine, you can now open a PR against the kernel-crawler main branch.\nOnce the PR is merged, and a new release tagged, you can expect next crawler run to fetch kernel lists for your new distro!\nDriverkit NOTE: this step is only needed if driverkit does not already support the distro.\nDriverkit is the falcosecurity solution to build Falco drivers (both kmod and eBPF probe) against any kernel release.\nIt internally uses docker or kubernetes runners to fetch the kernel headers and then builds drivers against them.\nDriverkit is also capable of finding correct headers to be used given a target distro and a kernelrelease.\nUnfortunately, this internal logic is in no way as smart as the kernel-crawler one (given that it does not really crawl anything, but just builds up expected headers urls using custom logic for each supported distro), therefore the preferred method is to always enforce the kernelurls parameter to pass required urls, and that logic should be treated as a fallback instead. This is what test-infra does, by thew way.\nEach driverkit builder is composed of a Go source file plus a small bash script template. The template gets filled with data during the run, and will be the exact bash script that gets ran in the container to build the drivers.\nTo add a new builder, there is a comprehensive documentation in the driverkit repo itself: https://github.com/falcosecurity/driverkit/blob/master/docs/builder.md.\nMake sure to follow the guide and then test that you are able to build drivers for the new distro, before opening the PR!\nOnce the PR is merged, and a new Driverkit release is tagged, you can go on to Falco repo.\nFalco NOTE: this step is only needed if falco-driver-loader::get_target_id needs tricks to pick up the correct target id (see eg: \u0026quot;flatcar\u0026quot; or \u0026quot;minikube\u0026quot; cases)\nFalco ships a not-so-tiny bash script, under scripts/falco-driver-loader, that is used at runtime to either:\ndownload a prebuilt driver from https://download.falco.org try to build a driver It supports both eBPF and kmod of course; to download the prebuilt driver, the script must be able to re-create the name used to push the artifact on the s3 bucket.\nThe most important function, for this, is the get_target_id one, that basically fetches the target distro that we are running.\nIdeally, no change will be needed in falco-driver-loader script, given that get_target_id fallbacks at parsing OS_ID from /etc/os-release file.\nOther times, like for example \u0026quot;amazonlinux\u0026quot;, \u0026quot;minikube\u0026quot; or \u0026quot;flatcar\u0026quot;, there is need to compute the correct parameters to match the ones used by pushed artifacts.\nIn these cases, a change is needed. Unfortunately, as of today, the falco-driver-loader is bundled within each Falco release, therefore each change will be reflected after a new Falco release, making the process a bit slow.\nWe can still manage to make an ad-hoc patch release though; feel free to ask maintainers to do so during a community call or on slack channel.\nTest-infra Test-infra is the repository mirroring kubernetes/test-infra, where our internal infra is maintained.\nIt also has an eks cluster where we run the drivers building jobs.\nUnder the hood, is uses Prow from kubernetes as a CI system. You can easily check our Prow jobs queue here: https://prow.falco.org/; moreover, you can also access monitoring at: https://monitoring.prow.falco.org/.\nLuckily, the required changes for the test-infra repo are really simple.\nIf a new driverkit release was needed, we need to bump the driverkit version in the build-drivers image.\nThen, we will need to add a prow job for the new distro; as you can imagine, the easiest thing is to start from another distro job, and update the required lines.\nHead to config/jobs/build-drivers folder and copy/paste build-new-debian.yaml content to the newly created build-new-arch.yaml.\nFinally, open the new file and update all debian references to arch (remember the ID loaded from /etc/os-release?).\nYou should be ready to open the PR! Once it gets merged, you will enjoy all the new shiny prebuilt drivers on https://download.falco.org as soon as the kernel-crawler runs again!\nReferences Following are the list of PRs needed to add support for AmazonLinux2023, as a reference:\nkernel-crawler: https://github.com/falcosecurity/kernel-crawler/pull/118 driverkit: https://github.com/falcosecurity/driverkit/pull/268 Falco: https://github.com/falcosecurity/falco/pull/2494 test-infra: https://github.com/falcosecurity/test-infra/pull/1099 Conclusion It seems like a ton of work, uh?\nIndeed, the whole procedure can take a bit of time. But fear not!\nFalcosecurity maintainers will be there to help you and guide you through all of the process! :rocket:\nWe hope to have clarified the procedure a bit, and we are looking forward for your next contributions! Bye!\n","summary":"","tags":null,"title":"Add prebuilt drivers for new distro","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-prebuilt-drivers-new-distro/"},{"category":"blog","content":"TLDR; Falco users prefer deploying on AWS and adopting it for security threat detection, auditing and compliance, and sandbox testing. Security and DevOps teams are the most common users of Falco. The official Helm chart and official container images are the preferred deployment methods. Respondents reported kernel module/eBPF probes installations, rule management, and integration with third parties as the main challenges. The most commonly used Falcosidekick integrations include Slack, PagerDuty, CloudWatch, and Elasticsearch. Suggestions for improving documentation include more examples, use cases, and platform compatibility information. Community support received a high satisfaction rating of 4.2 out of 5. One-third of respondents were active contributors, while the majority were not interested in sharing their Falco adoption story. Review the full report. Diving into the Falco community survey, this report unveils the fascinating world of Falco adoption and usage. As an open source cloud-native runtime security project, Falco has captured the attention of a diverse audience. This survey reached out to community members across various channels, including Slack, mailing lists, and social media platforms.\nDelving into various aspects of Falco adoption, this report uncovers insights on user roles, cloud providers, adoption motivations, deployment strategies, rule sets, challenges, and integrations. It also highlights areas that need improvement, like documentation and support, to enhance the overall experience for newcomers. These valuable insights will help guide the evolution of Falco, making it an even more robust and user-friendly cloud-native runtime security solution.\nRespondents' Roles Of the 24 individuals who participated in the survey, 22 shared their professional roles. These participants showcased a vibrant mix of positions, such as Software Engineers, DevOps practitioners, Cloud Architects, Security Engineers, Solutions Architects, Product Managers, CEOs, and even ambitious Student Developers. This colorful blend of roles demonstrates that Falco has captured the attention of a wide array of professionals from various fields and levels of expertise.\n1. What is your role?\nTotal respondents: 22 (out of 24 answered). Roles included: Director of DevOps and Cybersecurity, Software Engineer, Founder/Cloud Architect, Product, DevOps, Senior Solutions Architect, Security Engineer, CEO, Principal MTS, Cloud Architect, Senior DevOps, Solutions Architect, and Student Developer. Reasons for Adopting Falco Security threat detection tops the list as the driving force behind Falco adoption, followed closely by auditing and compliance. Sandbox testing and incident response are also cited as compelling reasons to embrace Falco. Notably, one participant isn't using Falco, while a couple of others leverage its libraries and policy language within their unique open source projects. These findings highlight Falco's versatility in catering to diverse security requirements across numerous domains.\n2. Why are you adopting Falco?\nMajority adopted Falco for security threat detection (58.3%). Auditing and compliance were common reasons (45.8% each). Sandbox testing and incident response also mentioned. Unique use cases: integrating Falco libraries into projects. Growing popularity as versatile security solution across fields. Teams Using Falco Falco predominantly finds a home within security teams, though DevOps squads are also known to harness its capabilities. Other adopters include platform engineering units, R\u0026amp;D departments, agent developers, and solution architects in the early stages of adoption. Interestingly, some survey participants don't use Falco at all, while others opt for its libraries directly, bypassing the full solution to meet their unique needs.\n3. Which teams use Falco at your company?\nSecurity teams most common users (45.8%). DevOps teams also prominent (41.7%). Platform engineering, R\u0026amp;D, agent developers, and early-adopting solution architects mentioned. 25% reported no Falco usage in their company. Some teams utilize Falco libraries directly. Falco Deployment Methods Most Falco enthusiasts opt for the official Helm chart when it comes to deployment, but the Falco community is nothing if not creative. Some users prefer official container images, bespoke manifest files, or even official packages like .deb, .rpm, and .tar.gz. Meanwhile, others have ventured off the beaten path, experimenting with custom shell script wrappers atop Helm, homegrown repositories for source compilation, tailor-made Helm charts combined with custom-built container images, or integrating Falco libraries directly into their agent and kernel modules. The sky's the limit when it comes to deploying Falco!\n4. How are you deploying Falco?\nMajority using official Helm chart (62.5%). Official container images (20.8%). Custom manifest files (16.7%). Official packages (.deb/.rpm/.tar.gz) (12.5%). Various alternative methods (16.7%). Rulesets Most users rely on the default ruleset when using Falco, while a significant number of users prefer to maintain their own ruleset to tailor it to their specific needs. Others choose to take advantage of the new ruleset feature to further enhance their security. The flexibility and adaptability of Falco's ruleset options provide users with a customized and comprehensive approach to their security needs.\n5. What ruleset do you use with Falco?\nDefault ruleset used by 54.2%. 50% maintain their own ruleset. New ruleset feature utilized by 29.2%. Other methods account for 4.2%. Challenges adopting Falco The survey revealed some of the key challenges encountered when adopting Falco. Top among them were kernel module and eBPF probes installations, and management of rules. Other difficulties included integrations with third-party tools, tuning, plugin management, and deployment. A few respondents indicated that they did not use Falco or faced other challenges. Additionally, a couple of participants mentioned their struggle with integrating Falco's security event logs with AWS CloudWatch, while others reported difficulties integrating with AWS FireLens and FluentBit log event forwarding. These challenges demonstrate the importance of ongoing development and improvement of Falco's features and documentation to make it a more seamless and user-friendly security solution.\n6. What challenges have you faced with adopting Falco?\nThe top two challenges faced by adopters of Falco were kernel module/eBPF probe installations (41.7%) and management of rules (41.7%). Integrations with third parties were also identified as a challenge by 37.5% of the respondents. Tuning, management of plugins, and performance were also mentioned as challenges by a significant number of participants (33.3%, 29.2%, and 16.7%, respectively). Some respondents (12.5%) indicated that they do not use Falco, while others mentioned other challenges, such as integrating Falco security event logs with AWS CloudWatch and using AWS FireLens and Fluent Bit log event forwarding. Falcosidekick integrations The survey sought to identify Falcosidekick integrations in use and what new integrations the community would like to see. Out of the 24 participants, 13 answered this question, with Slack, PagerDuty, and CloudWatch being the most commonly used integrations. Elasticsearch, AWS Lambda, and custom integrations were also mentioned, while one respondent highlighted that they use a fluentbit sidecar container instead of Falcosidekick to populate additional cloud metadata about each node.\nOn the other hand, when asked about integrations they would like to see, some participants expressed interest in Falcosidekick being usable by other threat detection systems like Tetragon. Others mentioned a desire for direct integrations with CloudWatch and/or Container Insights, as well as more cloud outputs. These results highlight the diverse integrations already in use, while identifying areas where the Falcosidekick community would like to see further development and expansion.\n7. What integrations with Falcosidekick are you using? What would you like to see?\nSlack, PagerDuty, and CloudWatch are the most commonly used integrations with Falcosidekick, among the 13 participants who answered this question. Some respondents expressed interest in additional integrations, such as Elastic search, AWS Lambda, custom ones, and falco-exporter. One participant mentioned they would like Falcosidekick to be usable by other threat detection systems like Tetragon. Others expressed interest in direct integrations with CloudWatch and/or Container Insights, as well as more cloud outputs. A few respondents mentioned that they do not use Falcosidekick and instead push events directly to things like S3 or Elastic. Plugins Out of 24 respondents, 12 answered the question on their usage and desired integrations of Falco plugins. The k8s_audit plugin was the most commonly used, followed by Cloudtrail and k8saudit. Some respondents also mentioned using plugins for audit logging and GitHub. However, a notable number of participants did not use any Falco plugins.\nRegarding desired integrations, a few respondents expressed interest in more diverse plugins, such as EKS Kubernetes kernel monitoring, which could enhance the monitoring of their Kubernetes infrastructure. Other respondents suggested new plugins for monitoring and analyzing different system events, such as DNS resolution or SSL handshake failures. The results suggest that there is a desire for more plugins that can address diverse security issues in different system components.\n8. Which plugin(s) are you using? What would you like to see?\nk8s_audit and Cloudtrail are the most commonly used plugins among the respondents. Several participants mentioned using a combination of plugins such as K8saudit, Cloudtrail, and JSON. Some respondents do not use any plugins or did not provide a response. One participant mentioned using EKS Kubernetes kernel monitoring, while another used audit logging. Github integration was also mentioned by a couple of respondents. There were no clear requests for new plugins or features, although some participants did not provide a response to this question. Documentation The survey asked participants to rate Falco's documentation on a scale from 1 to 5, with 5 being \u0026quot;very helpful\u0026quot; and 1 being \u0026quot;not helpful.\u0026quot; All 24 participants responded to this question, and the average rating for Falco's documentation was 3.7. While this is a solid rating, it indicates that there is room for improvement. Some participants rated Falco's documentation as highly helpful (with ratings of 4 or 5), while others found it to be less helpful (with ratings of 1 or 2). The survey data highlights the importance of clear and concise documentation to assist users in getting the most out of Falco.\n9. On a scale of 1 - 5, how would you rate Falco’s documentation?\nThe average rating was 3.7. 41.7% of respondents rated the documentation 2 out of 5. 29.2% of respondents rated the documentation 3 out of 5. 25% of respondents rated the documentation 4 out of 5. 4.2% of respondents rated the documentation 1 out of 5. Onboarding and getting started The survey asked respondents about their opinions on the type of documentation and support that would improve the onboarding and getting started experience for new community members. Out of 24 participants, 16 provided their valuable feedback. The respondents highlighted the need for more examples, tutorials, and step-by-step guides, especially around rule configuration and integration with cloud providers' services like AWS CloudWatch. Other requests included more detailed information on what Falco can and cannot do, more manuals, and more working samples of integrations with AWS Services and different ways to aggregate and route security events.\nOne participant suggested the need for documentation around the probes, which includes information on when to use one probe over the other, what platforms each probe works with, and insights into typical reasons why a module fails when it does. Additionally, they highlighted the importance of clarifying which platforms are supported, as there were unclear requests around things like k3.\nOther recommendations included a contributing guide and templates, end-to-end tutorials from Hello World to complex use cases, and more use cases on public cloud offerings. Respondents emphasized the importance of having up-to-date documentation that keeps pace with the fast-moving nature of Falco. Overall, the survey results provide valuable insights for the Falco community to improve the onboarding and getting started experience for new members, ultimately creating a more user-friendly and accessible cloud-native runtime security project.\n10. What type of documentation and support do you believe is needed to improve the onboarding and getting started experience for new community members?\nImproving documentation and support can enhance the onboarding and getting started experience for new members of the Falco community. Respondents suggest more examples, tutorials, use case implementation tutorials, and specific examples of custom security monitoring with rules configuration and integration with cloud providers' services. Respondents also suggest more working samples of integrations with AWS services, more information on probes, documentation recency, and freshness, and more analysis of performance impact across different workload types. Community support The survey measured the quality of community support for Falco on a scale of 1-5, with an average rating of 4.2, indicating that the majority of respondents found it very helpful. This positive feedback reflects the strength of the Falco community's willingness to provide support to new members, highlighting the essential role of community support in the success of open source projects. A small number of respondents rated Falco's community support as not helpful, with others rating it as somewhat helpful or neutral. Overall, the survey results suggest that the Falco community is a valuable resource for those seeking support and guidance.\n11. On a scale of 1 - 5, how would you rate Falco’s community support?\nAll 24 respondents rated Falco's community support on a scale of 1-5, with an average rating of 4.2. Over 45% of respondents rated the community support as \u0026quot;Very helpful\u0026quot; (5), while 37.5% rated it as \u0026quot;Helpful\u0026quot; (4). Only one respondent rated the community support as \u0026quot;Not helpful\u0026quot; (1). The results indicate that Falco has a strong and supportive community, with the majority of respondents finding the support helpful or very helpful. Contributing to Falco The results highlight a mix of engagement levels within the community and potential for increased involvement from those who would like to contribute.\n12. Are you an active contributor to the project?\nOut of 24 respondents, 33.3% were active contributors to the Falco project. An equal percentage of respondents (33.3%) expressed interest in becoming contributors in the future. 33.3% of respondents were not active contributors to the project. Community communication When it comes to effective communication, Falco is hitting the mark according to a survey that asked users to rate their satisfaction on a scale of 1-5. With an average rating of 4.2 out of 5, most respondents rated Falco's communication as satisfactory or even highly satisfactory. Only a few rated it as not satisfactory, with the rest expressing neutrality or some level of satisfaction. These results suggest that while Falco is doing well in communicating with its community, there is still potential to further enhance communication to meet the diverse needs of its users.\n13. On a scale of 1 - 5, how satisfied are you with the communication of the Falco project?\nThe survey asked participants to rate their satisfaction with the communication of the Falco project on a scale of 1-5. The average rating of the Falco project's communication was 4.2. A majority of respondents rated Falco's communication as either highly satisfactory (37.5%) or satisfactory (50%). Only a small percentage of respondents were either neutral or not satisfied with Falco's communication (8.3% and 4.2% respectively). These results demonstrate that overall, respondents are satisfied with the communication of the Falco project. Weekly community calls Falco's community calls are an essential part of its communication strategy, allowing users to connect and collaborate with other members of the community. The survey asked participants whether they attend these calls, with 24 out of 24 respondents answering. The results showed that a majority of respondents do not attend the weekly community calls, with an almost equal number of respondents indicating they are planning to attend in the future. A smaller number of respondents attend the calls from time to time, and only a few respondents attend almost every week. These results highlight the importance of ensuring that community calls are accessible and convenient for all members, and that alternative ways of communication are available for those unable to attend.\n14. Do you attend the weekly community calls?\n29.2% of respondents do not attend the calls. Another 29.2% are not attending, but plan to in the future. Another 29.2% attend the calls from time to time. Only 12.5% of respondents attend the weekly community calls almost every week. Sharing your adoptiong journey Falco's adopters are a proud community, and the project provides opportunities to share their success stories. In a survey of 24 participants, the question of whether they were interested in sharing their Falco adoption story and publishing their company's name in Falco's adopters file was asked. Over half of the respondents (54.2%) preferred not to share their story, while 25% of the respondents were interested in sharing it privately with the maintainers. Meanwhile, 20.8% were enthusiastic about sharing it publicly. These results demonstrate that while many companies may not want to publicize their use of Falco, some are excited to share their adoption story with the larger community.\n15. Are you interested in sharing your Falco adoption story and publishing the your company's name in Falco's adopters file?\n54.2% of respondents were not interested in sharing their Falco adoption story, and preferred that it not be shared at all. 25% of respondents were willing to share their story, but only privately with the maintainers. 20.8% of respondents were willing to share their story publicly. All 24 respondents answered this question. Conclusion The Falco community survey provides valuable insights into the experiences and opinions of users in the community. Overall, the survey results demonstrate a high level of satisfaction with Falco, with users praising its effectiveness, ease of use, and flexibility. However, there are areas where the community would like to see further development and expansion, particularly in documentation, integrations, and communication.\nAdditionally, the survey shows that the Falco community is a diverse group of users from various industries and backgrounds, with different levels of expertise and use cases. It is clear that the Falco project has a strong and supportive community, and its continued growth and success rely on the continued engagement and contributions of its users.\n","summary":"","tags":null,"title":"Falco Community Survey 2023","url":"https://v0-43--falcosecurity.netlify.app/blog/community-survey-2023/"},{"category":"blog","content":"We are happy to announce that in early 2023 the Falco project completed a security audit sponsored by the CNCF, with support from the Open Source Technology Improvement Fund and conducted by the security experts at Quarkslab SAS. The audit was focused on identifying security issues in the codebase and providing suggestions for implementing more static and dynamic security analysis strategies to help continuously maintain high security standards in the project.\nA group of Falco maintainers volunteered to provide help and collaborated with the team every step of the way, including defining a threat model, navigating the codebase and agreeing on static and dynamic analysis recommendations.\nFindings and available patches The full report is available in the Falco repository (pdf). In a nutshell, the report identified one medium severity finding and a number of low and informational severity findings. There were no high or critical severity vulnerabilities and the findings were not found to be likely to be exploited with significant impact.\nWe worked to address all the findings in our most recent releases. The Falco 0.34.0 release and 0.34.1 patch release launched February 2023 based on Falco Libraries 0.10.3 and 0.10.4 addressed all the medium and low severity findings, along with informational findings as well. Details on the issues, credits, patches and affected versions have been published in the relevant repository security advisories as soon as the fixes were available.\nStatic and dynamic analysis enhancements One very important aspect of this audit is that the team worked on providing valuable suggestions to strengthen static and dynamic analysis of the entire codebase. We have already enhanced our CI/CD pipelines with additional CppCheck steps in the Falco CI. The community has also decided to integrate Semgrep to prevent potentially dangerous functions from being added and extend our AddressSanitizer and LeakSanitizer coverage, with even more additions to come.\nAnother very interesting part of the report concerns the technical challenges of implementing a fuzzer for a project as complex as Falco. By leveraging the expertise shared by the audit team in the report, we believe it is possible to build a robust fuzzer that can run continuously. According to the report it is not an easy project but certainly a worthwhile one.\nConclusions and thanks Security is a never ending task, and the Falco community is always very happy and eager to collaborate with security experts to make all aspects of Falco more secure.\nThe Falco maintainers had a pleasant experience working with the Quarkslab team and we appreciate the smooth communication while sharing security and engineering knowledge. The community is pleased with the overall high quality of this work.\nWe wish to thank all of the following Falco project maintainers who were involved in the audit Fred Araujo, Jason Dellaluce, Mauro Moltrasio, Leonardo Grasso, Luca Guerra, Teryl Taylor and Michele Zuccala, we appreciate your assistance and knowledge sharing with the Quarkslab team. Big thank you to the Quarkslab team too: Frédéric Raynal, Ramtine Tofighi Shirazi, Victor Houal, Laurent Laubin and Mahé Tardy and the OSTIF team for facilitating and sponsoring the project: Derek Zimmer and Amir Montazery.\n","summary":"","tags":null,"title":"The 2023 Falco Security Audit","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-security-audit-2023/"},{"category":"blog","content":"Last November at re:Invent (2022) AWS introduced the new security oriented data lake: Amazon Security Lake. The AWS team leading the development of the new service contacted the Falco community and proposed a collaboration to develop the first custom source. We greatly accepted and partnered with AWS engineers to prepare a new plugin and service announcement. To support the community with this integration we are introducing best practices for getting started with the AWS Security Lake and Falco plugin.\nThis blog post describes key concepts around the integration of AWS Security Lake as output for Falco through Falcosidekick in EKS and how to get started.\nConcepts OCSF Parquet Register Falco as Custom Source Configuration of Falcosidekick Deployment of Falco \u0026amp; Falcosidekick Results Falcosidekick logs In S3 Conclusion Concepts OCSF Since AWS follows the Open Cybersecurity Schema Framework (OCSF) for event format, ensure that you have the same standard. This helps to facilitate the extension to a multiple number of sources and consumers. For Falco events, as they may match to several use cases, they can be extended to additional sources by leveraging plugins. The recommended schema to use is: Security Finding. Falcosidekick will be in charge of converting the Falco events into a JSON payload with the following schema.\nParquet AWS Security Lake requires to group events in parquet files format, this best practices optimizes for analysis and treatments. Once again, Falcosidekick will receive these events from Falco, group them into a parquet file and upload them to your S3 bucket, running continuously every 5 minutes (it's a requirement from AWS Security Lake, for better analysis, it requires a minimum of 5 minutes between two files).\nRegister Falco as Custom Source For custom sources, Amazon Security Lake is responsible for provisioning the S3 bucket location, creating the Lake Formation table associated with that location, creating a role in the customer’s account that will be used to write the custom source data, setting up a Glue crawler to maintain partition metadata, and coordinating subscriber access to the source after it is written to Amazon Security Lake.\nPlease follow the official documentation to register Falco as a custom source.\nThe OCSF Event class to use is Security Finding and we'll name our custom source falco\nYou should now have the name of the bucket, the prefix and the role to use in the configuration.\nFor the bucket, the pattern will be s3://aws-security-data-lake-{region}-xxxx/ext/falco with:\nbucket: aws-security-data-lake-{region}-xxxx prefix: ext/falco/ For the role, 2 roles have been created:\narn:aws:iam::{accountID}:role/service-role/AmazonSecurityLakeCustomDataGlueCrawler-falco arn:aws:iam::{accountID}:role/service-role/AmazonSecurityLake-Provider-falco-{region} We will use the role arn:aws:iam::{accountID}:role/service-role/AmazonSecurityLake-Provider-falco-{region} as IRSA.\nUpdate its Trust relationships as follow (adapt the values to your env) to allow your deployment of Falcosidekick to use it.\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Principal\u0026#34;: { \u0026#34;AWS\u0026#34;: \u0026#34;arn:aws:iam::{accountID}:root\u0026#34; }, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRole\u0026#34; }, { \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Principal\u0026#34;: { \u0026#34;Federated\u0026#34;: \u0026#34;arn:aws:iam::{accountID}:oidc-provider/oidc.eks.{region}.amazonaws.com/id/xxxx\u0026#34; }, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRoleWithWebIdentity\u0026#34;, \u0026#34;Condition\u0026#34;: { \u0026#34;StringEquals\u0026#34;: { \u0026#34;oidc.eks.{region}.amazonaws.com/id/xxxx:sub\u0026#34;: \u0026#34;system:serviceaccount:falco:falco\u0026#34;, \u0026#34;oidc.eks.{region}.amazonaws.com/id/xxxx:aud\u0026#34;: \u0026#34;sts.amazonaws.com\u0026#34; } } } ] } For the OIDC details, replace the xxxx by the result of the command:\naws eks describe-cluster --name {cluster-name} --query \u0026#34;cluster.identity.oidc.issuer\u0026#34; --output text | cut -d \u0026#39;/\u0026#39; -f 5 Note: for that, you must have created an OIDC prodiver your cluster. See the docs.\nConfiguration of Falcosidekick Since you made it this far it means that you have everything ready on AWS' side, now it's time to configure Falco and Falcosidekick. The easiest way to get started is by using the official Helm chart.\nTo configure Falcosidekick at minimum use this values.yaml with all the necessary values to complete the configuration, see here:\nfalcosidekick: enabled: true aws: rolearn: \u0026#34;arn:aws:iam::{accountID}:role/service-role/AmazonSecurityLake-Provider-falco-{region}\u0026#34; checkidentity: false securitylake: bucket: \u0026#34;aws-security-data-lake-{region}-xxxx\u0026#34; prefix: \u0026#34;ext/falco\u0026#34; region: \u0026#34;{region}\u0026#34; accountid: \u0026#34;{accountID}\u0026#34; interval: 5 batchsize: 1000 Details to note about the settings:\nrolearn: the ARN of the role created by AWS Security Lake at the Custom Source registration, see above. checkidentity: must be set to false because the role created by AWS Security Lake doesn't allow to call sts:GetCallerIdentity securitylake.bucket: the bucket name returned by AWS Security Lake at Custom source registration (mandatory to enable the output) securitylake.prefix: the prefix returned by AWS Security Lake at Custom source registration (mandatory to enable the output) securitylake.region: the region of the events, as a single bucket can store events from different regions (mandatory) securitylake.accountId: the accountId of the account where the events have been created, as a single bucket can store events from different accounts (mandatory) securitylake.interval: time in minutes between 2 PUTs of parquet files into S3 to follow the service's requirements securitylake.batchsize: max number of events by parquet file, to avoid to reach max allowed size Deployment of Falco \u0026amp; Falcosidekick These classic Helm commands will deploy everything for you:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update helm install falco -n falco -f values.yaml --create-namespace The Falco and Falcosidekick configurations are almost ready, the next step is getting the following logs into the Falcosidekick pods:\n2023/03/13 13:03:06 [INFO] : Enabled Outputs : [AWSSecurityLake] 2023/03/13 13:03:06 [INFO] : Falco Sidekick is up and listening on :2801 Falcosidekick is ready to receive events and upload them into Amazon Security Lake!\nResults Falcosidekick logs When Falco triggers any rules, Falcosidekick will receive and queue them every 5 minutes, then it will create a parquet file and load them into the S3 bucket:\n2023/03/13 13:28:18 [INFO] : AWS SecurityLake. - Event queued (bcc55fc3-c0ab-434f-9921-d76f232ce0aa) 2023/03/13 13:28:37 [INFO] : AWS SecurityLake. - Event queued (26a482e8-7282-4bee-bd7f-7491112b7568) 2023/03/13 13:29:06 [INFO] : AWS SecurityLake. - Event queued (13e59c53-e1a4-4876-ba5e-a77de9d07e3c) 2023/03/13 13:29:16 [INFO] : AWS SecurityLake. - Event queued (0bb6fef3-1ac4-4cc8-a12f-e60250ad48ff) 2023/03/13 13:29:41 [INFO] : AWS SecurityLake. - Event queued (6c92eeef-98d5-4064-8a91-55bf675532a1) 2023/03/13 13:30:06 [INFO] : AWS SecurityLake. - Event queued (e1cc973f-6153-45a7-813a-a8793f146144) 2023/03/13 13:30:20 [INFO] : AWS SecurityLake. - Event queued (d28cf6c9-3503-448f-a3c4-6e132743af5e) 2023/03/13 13:30:30 [INFO] : AWS SecurityLake. - Event queued (af9aa6c1-c75c-453e-ae1d-947c6b6735c6) 2023/03/13 13:30:56 [INFO] : AWS SecurityLake. - Event queued (b51449f4-bb2d-4ce4-afd8-397bf28b3345) 2023/03/13 13:31:17 [INFO] : AWS SecurityLake. - Event queued (8a51e8f2-9b78-4aa1-a9e6-55f304c6bea6) 2023/03/13 13:31:37 [INFO] : AWS SecurityLake. - Event queued (38985e4a-be74-4033-b807-724caac55f7b) 2023/03/13 13:31:41 [INFO] : AWS SecurityLake. - Event queued (ad8e0bc7-e0c2-4583-9c10-561786268355) 2023/03/13 13:31:42 [INFO] : AWS SecurityLake. - Event queued (72a002f0-9460-4fe9-af6a-d05f35d65707) 2023/03/13 13:32:00 [INFO] : AWS SecurityLake. - Event queued (4986a846-c086-4d06-8b10-eec31132a465) 2023/03/13 13:32:28 [INFO] : AWS SecurityLake. - Event queued (1000b0fe-76d2-4eba-b7cc-84e1bf0f8a53) 2023/03/13 13:32:50 [INFO] : AWS SecurityLake. - Event queued (ec9c4cd3-d705-4bd4-bb51-4a7cb4ee4b4c) 2023/03/13 13:33:15 [INFO] : AWS SecurityLake. - Upload parquet file d6b40894-f53c-46b3-9f85-67a7fbbdd56b.parquet OK (16 events) In S3 If you take a look at your S3 console now, you'll see the resulting parquet files, correctly ordered by region, account id and day in your AWS Security Lake bucket:\nConclusion We hope this step by step blog helps the AWS \u0026amp; Falco community get easily started using this integration. We would like to thank the AWS team for partnering with Falco and the invitation to participate in the AWS Security Lake project launch. It has been a great partnership since the beginning, we are also so appreciative of the contributions and support during the development of the integration in Falcosidekick. The goal of the post is help you get all of your configurations ready to enable the transfer of Falco events into AWS Security Lake. If you have any issues or requests, please join us on Slack.\nPer usual, if you have any feedback or need help, you can find us at any of the following locations.\nGet started in Falco.org Check out the Falcosidekick project on GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":null,"title":"Falco and AWS Security Lake","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-aws-security-lake/"},{"category":"blog","content":"Since the launch of the plugin framework in January 2022, our adopters have requested an out-of-the-box solution to manage the lifecycle of rules (installation, updates). We heard your request and also created a guide to help you smoothly install the plugins. The Falco maintainers proposed the following solution to help with these issues: falcoctl. Falcoctl is a CLI tool that performs several useful tasks for Falco.\nThis blog post describes key concepts around falcoctl to help you get started.\nGlossary Use falcoctl locally Installation Index Configuration Search for artifacts Installation of artifacts Installation of Rules Installation of Plugins Follow artifacts Systemd service Use falcoctl in Kubernetes with Helm Add the official Helm repo Configure the installation and followed by the artifacts Disable falcoctl in the chart Conclusion Glossary Before diving into all the details, here's a glossary of the key words to understand how falcoctl works. An exhaustive list can be found in the README.\nArtifact: An artifact is an element falcoctl can manipulate, right now, only rulesfiles and plugins are considered. Index: A .yaml file containing a list of available artifacts with their registries and repositories. The tool's default configuration contains an index file pointing to the officially supported artifacts from the falcosecurity organization, see here. Users can also maintain their own index files, pointing to registries and repositories containing custom rulesfiles and plugins. Registry: A registry stores the artifacts, that falcoctl understands in regards to the OCI standard, any compliant OCI can be used. The official registry uses Github Packages. Repository: similar to containers, it belongs to a registry and contains one or more versions (tags) of an artifact. Use falcoctl locally The following steps explain the basic concepts used to install falcoctl locally.\nInstallation For a Linux amd64 system:\nLATEST=$(curl -sI https://github.com/falcosecurity/falcoctl/releases/latest | awk \u0026#39;/location: /{gsub(\u0026#34;\\r\u0026#34;,\u0026#34;\u0026#34;,$2);split($2,v,\u0026#34;/\u0026#34;);print substr(v[8],2)}\u0026#39;) curl --fail -LS \u0026#34;https://github.com/falcosecurity/falcoctl/releases/download/v${LATEST}/falcoctl_${LATEST}_linux_amd64.tar.gz\u0026#34; | tar -xz falcoctl sudo install -o root -g root -m 0755 falcoctl /usr/local/bin/falcoctl Other environments are described in the README\nNow you are able to confirm that the installation went well. Check the version:\n❯ falcoctl version Client Version: 0.4.0 Print the help:\n❯ falcoctl --help __ _ _ _ / _| __ _| | ___ ___ ___| |_| | | |_ / _ | |/ __/ _ \\ / __| __| | | _| (_| | | (_| (_) | (__| |_| | |_| \\__,_|_|\\___\\___/ \\___|\\__|_| The official CLI tool for working with Falco and its ecosystem components. Usage: falcoctl [command] Available Commands: artifact Interact with Falco artifacts completion Generate the autocompletion script for the specified shell help Help with any command index Interact with index registry Interact with OCI registries tls Generate and install TLS material for Falco version Print the falcoctl version information Flags: --config string config file to be used for falcoctl (default \u0026#34;/etc/falcoctl/falcoctl.yaml\u0026#34;) --disable-styling Disable output styling such as spinners, progress bars and colors. Styling is automatically disabled if not attached to a tty (default false) -h, --help help for falcoctl -v, --verbose Enable verbose logs (default false) Use \u0026#34;falcoctl [command] --help\u0026#34; for more information about a command. Index Before being able to download and install artifacts, we need to configure an index, we provide one for all official artifacts, plugins and rules:\nsudo falcoctl index add falcosecurity https://falcosecurity.github.io/falcoctl/index.yaml To confirm the installation:\n❯ sudo falcoctl index list NAME URL ADDED UPDATED falcosecurity https://falcosecurity.github.io/falcoctl/index.yaml 2023-02-14 14:57:33 2023-02-14 15:48:43 The index is not automatically updated, when a new artifact is added to the list, you can refresh your local cache with:\nsudo falcoctl index update falcosecurity Configuration The default configuration of falcoctl is /etc/falcoctl/falcoctl.yaml, as it can store secrets, like credentials to private registries, the file is protected by default.\n❯ sudo cat /etc/falcoctl/falcoctl.yaml indexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml To know more about available settings, see the official docs.\nSearch for artifacts Everything is set up and ready. We can search for new artifacts:\n❯ sudo falcoctl artifact search falco INDEX ARTIFACT TYPE REGISTRY\tREPOSITORY falcosecurity\tfalco-rules\trulesfile\tghcr.io falcosecurity/rules/falco-rules ❯ sudo falcoctl artifact search kubernetes INDEX ARTIFACT TYPE REGISTRY REPOSITORY falcosecurity k8saudit plugin ghcr.io falcosecurity/plugins/plugin/k8saudit falcosecurity k8saudit-rules rulesfile ghcr.io falcosecurity/plugins/ruleset/k8saudit Note the TYPE column to determine the kind of artifact.\nThe search is made through names and keywords as we can find them in the index.yaml:\n- name: k8saudit type: plugin registry: ghcr.io repository: falcosecurity/plugins/plugin/k8saudit description: Read Kubernetes Audit Events and monitor Kubernetes Clusters home: https://github.com/falcosecurity/plugins/tree/master/plugins/k8saudit keywords: - audit - audit-log - audit-events - kubernetes license: Apache-2.0 maintainers: - email: cncf-falco-dev@lists.cncf.io name: The Falco Authors sources: - https://github.com/falcosecurity/plugins/tree/master/plugins/k8saudit Installation of artifacts Installation of Rules It's time to install our first artifact, the beloved falco default rules.\n❯ sudo falcoctl artifact install falco-rules INFO Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; INFO Resolving dependencies ... INFO Installing the following artifacts: [ghcr.io/falcosecurity/rules/falco-rules:latest] INFO Preparing to pull \u0026#34;ghcr.io/falcosecurity/rules/falco-rules:latest\u0026#34; INFO Pulling ad24f8acf278: ############################################# 100% INFO Pulling 0d3705a4650f: ############################################# 100% INFO Pulling 0957c1ef3fe4: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/etc/falco\u0026#34; By default, the latest version is used, but you can specify a targeted tag sudo falcoctl artifact install falco-rules:0.5.0.\nAll official artifacts come with floating tags, for example:\n0 for the last 0.x.x 0.5 for the last 0.5.x etc You can find the available versions (tags) with:\n❯ sudo falcoctl artifact info falco-rules REF TAGS ghcr.io/falcosecurity/rules/falco-rules\t0.0.0 0.1.0-rc1 0.1.0 0.1.0 latest You can also directly check in Github: https://github.com/falcosecurity/rules/pkgs/container/rules%2Ffalco-rules When you install a ruleset requiring specific plugins, the relative plugins are also installed!\n❯ sudo falcoctl artifact install k8saudit-rules:0.5 INFO Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; INFO Resolving dependencies ... INFO Installing the following artifacts: [ghcr.io/falcosecurity/plugins/ruleset/k8saudit:0.5 json:0.6.0 k8saudit:0.5.0] INFO Preparing to pull \u0026#34;ghcr.io/falcosecurity/plugins/ruleset/k8saudit:0.5\u0026#34; INFO Pulling cb5233c876c3: ############################################# 100% INFO Pulling 4383c69ba0ad: ############################################# 100% INFO Pulling 2c6ca9f7dac5: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/etc/falco\u0026#34; INFO Preparing to pull \u0026#34;ghcr.io/falcosecurity/plugins/plugin/json:0.6.0\u0026#34; INFO Pulling 65a28b294bff: ############################################# 100% INFO Pulling 15fb7eddd978: ############################################# 100% INFO Pulling f4ca8f34ad16: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/usr/share/falco/plugins\u0026#34; INFO Preparing to pull \u0026#34;ghcr.io/falcosecurity/plugins/plugin/k8saudit:0.5.0\u0026#34; INFO Pulling 3e249d372a35: ############################################# 100% INFO Pulling c4abb288df01: ############################################# 100% INFO Pulling 5e5cfe270518: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/usr/share/falco/plugins\u0026#34; Installation of Plugins Like rules, plugins can be installed with one simple command:\n❯ sudo falcoctl artifact install github INFO Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; INFO Resolving dependencies ... INFO Installing the following artifacts: [ghcr.io/falcosecurity/plugins/plugin/github:latest] INFO Preparing to pull \u0026#34;ghcr.io/falcosecurity/plugins/plugin/github:latest\u0026#34; INFO Pulling 19dc1c0f62a0: ############################################# 100% INFO Pulling d97aadfc1199: ############################################# 100% INFO Pulling 5b9143db2a1d: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/usr/share/falco/plugins\u0026#34; Easy!\nFollow artifacts A great feature of falcoctl is its ability to run as a daemon to periodically check the artifacts' repositories and automatically install new versions. The configuration of the behavior is also in /etc/falcoctl/falcoctl.yaml.\nindexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml artifact: install: refs: - k8saudit:0.5.0 follow: every: 6h0m0s falcoVersions: http://localhost:8765/versions refs: - k8saudit:-rules:0.5 The install section lists the references of the artifacts we want to install at deployment of falcoctl. The follow section lists those we want to automatically update and check every for frequency.\nSome plugins and rules versions depend on the falco version, falcoctl request, and the falco type of /versions and API endpoint that gather intel, this is why we have the falcoVersions field in the configuration.\nWe do not advise to disable the plugins, as they are binaries, and could lead to security breaks.\nSystemd service To help you set falcoctl as a daemon, here's a systemd service template /etc/systemd/system/falcoctl.service:\n[Unit] Description=Falcoctl After=network.target StartLimitIntervalSec=0 [Service] Type=simple Restart=always RestartSec=1 ExecStart=/usr/local/bin/falcoctl artifact follow To enable/start the new service:\n❯ systemctl enable falcoctl ❯ systemctl start falcoctl ❯ systemctl status falcoctl ● falcoctl.service - Falcoctl Loaded: loaded (/etc/systemd/system/falcoctl.service; static) Active: active (running) since Thu 2023-02-16 16:46:32 CET; 1h ago Main PID: 567876 (falcoctl) Tasks: 9 (limit: 38132) Memory: 6.8M CPU: 15ms CGroup: /system.slice/falcoctl.service └─567876 /usr/local/bin/falcoctl artifact follow Use falcoctl in Kubernetes with Helm The last version of the falco helm chart, v3.0.0 includes falcoctl as an init container and sidecar, to accordingly install and follow artifacts.\nAdd the official Helm repo Nothing new under the sun, a classic helm command:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update Configure the installation and followed by the artifacts Like any other values, we can set the values.yaml field to choose the artifacts to install and follow the index we use for.\n... falcoctl: artifact: install: enabled: true follow: enabled: true config: indexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml artifact: allowedTypes: - rulesfile - plugin install: resolveDeps: true refs: [k8saudit-rules:0.5, falco-rules:0] follow: refs: [k8saudit-rules:0.5, falco-rules:0] every: 6h ... The resolveDeps: true avoids listing the plugin at install, and will be automatically installed with the rules.\nHere's the final command to bootstrap a very basic installation with these settings:\nhelm install falco -n falco -f values.yaml falcosecurity/falco --create-namespace Disable falcoctl in the chart If for some reason you don't want to use falcoctl to manage artifacts, you can disable its installation by following these steps:\nhelm install falco \\ --set falcoctl.artifact.install.enabled=false \\ --set falcoctl.artifact.follow.enabled=false Conclusion In this blog post we learned some of the basic falcoctl usages that we can run locally and in our Kubernetes clusters with helm. It helps to manage the lifecycle of the rules and the plugins with an out of the box solution like falcoctl`. Stay tuned as the plugin ecosystem is growing and we are seeing the development of more features and enhancements. More posts will also be out soon to detail more advanced usages, such as using private registries and creating your own artifacts. See you soon!\nPer usual, if you have any feedback or need help, you can find us at any of the following locations.\nGet started in Falco.org Check out the Falcoctl project on GitHub. Check out the Falco Rules on GitHub. Check out the Falco Plugins on GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Rules","Falco Plugins","Falcoctl"],"title":"Falcoctl: install and manage your rules and plugins","url":"https://v0-43--falcosecurity.netlify.app/blog/falcoctl-install-manage-rules-plugins/"},{"category":"blog","content":"Today we announce the release of Falco 0.34.1 🦅!\nNovelties 🆕 and Fixes Here's a minor update! This patch release addresses small but persistent issues that have been causing inconvenience for users:\nhttp_output not working as expected when the remote endpoint was using the HTTPS protocol; FALCO_ENGINE_VERSION was bumped since in Falco 0.34.0 new event fields were added for the process events; cleanups and fixes related to memory management were introduced in libs; avoid file descriptor leakage when checking for online CPUs in libpman. Thanks to everyone in the community for helping us in spotting these annoying bugs 🐛! You make Falco successful 🦅!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nTry it! 🏎️ As usual, in case you just want to try out the stable Falco 0.34.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader What's next 🔮 It's an exciting time for Falco as we see so many great improvements and features. What's more exciting is the fact that many great ideas and awesome work are going on to make the next big things happen.\nThe upcoming release will include complete syscall support in the modern BPF probe (feature parity with kernel module and current BPF probe) and introduce adaptive syscall selection for the Falco ruleset.\nLet's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nAldo\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.34.1","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-34-1/"},{"category":"blog","content":"The new Falco Helm chart 3.0.0 (full documentation, upgrade information) comes with a new way to automatically update the Falco rules that are currently loaded. Of course, you can enable, disable and configure this functionality to your liking. Below, we list a number of common basic use cases and how to easily configure Falco for each:\nAutomatically update rules from the Falco organization If you install the new helm chart with:\nhelm install falco Falco, by default, will load the latest ruleset that is compatible with your Falco version and keep it up to date automatically. In Falco 0.34.0 this is the 0.x.x line of rules published by the Falco organization, following the tag 0 published on GitHub Packages.\nUse the rules embedded in the Falco image The Falco image ships with a snapshot of the latest version of the official Falco org rules. If you wish to use that without downloading anything at runtime you can install Falco with:\nhelm install falco \\ --set falcoctl.artifact.install.enabled=false \\ --set falcoctl.artifact.follow.enabled=false Add custom rules with a configmap On top of any scenario above you can add the customRules value to add your own custom rules in a configmap. For instance, if we create a file as described in the documentation and then add it to our one of the above command lines with:\n-f custom_rules.yaml It will be loaded and configured in our Falco instance.\nOnly use rules supplied via configmap If you only want to use the rules that you add via configmap, discarding all automated updates and default rules shipping in the image you have to remove the falco_rules.yaml entry from the Falco configuration. Assuming you have your custom rules in custom_rules.yaml:\nhelm install falco -f ./custom_rules.yaml \\ --set \u0026#34;falco.rules_files={/etc/falco/falco_rules.local.yaml,/etc/falco/rules.d}\u0026#34; \\ --set falcoctl.artifact.install.enabled=false \\ --set falcoctl.artifact.follow.enabled=false ","summary":"","tags":["Rules","Configuration Management"],"title":"Rule basics for the Falco 3.0.0 Helm chart","url":"https://v0-43--falcosecurity.netlify.app/blog/rules-helm-chart-3-0-0/"},{"category":"blog","content":"Dear community, today we are delighted to announce the release of Falco 0.34.0 🎉!\nA big thank you to the community for helping get the latest release out. The Falco community is thrilled about this release and cannot wait to share the latest goodies. Check out the newest features from this most recent launch to learn more ⬇️. To read a more detailed account of the release, see v0.34.0 in the changelog.\nWhat’s new? 🆕 In this release we saw more than 190 pull requests across the repos of Falco and its libraries. Thank you to our maintainers and contributors, as this would not happen without your support, dedication, and contribution.\nUpdates - TL;DR 🩳 In release v0.34.0 the community focused on addressing the following key features:\nDownloading and dynamically updating Falco rules at runtime Shipping the brand new experimental modern eBPF probe Designing more ways to catch suspicious executions Automatic rules update 🔄 A few questions that often come up when using Falco is how can we update rules once Falco is installed in the cluster and, how do we get updated rules from the Falco organization without having to wait for the next release? This is the first release to include falcoctl with an out of the box solution to do exactly that!\nWhen using the new Falco Helm Chart 3.0.0 rules will automatically be updated from the official repository. To learn more about this feature and how to configure it read the Helm chart documentation. Likewise, when using a SystemD based install you can configure Falco to automatically update rules.\nWant to upgrade to the new Helm chart? Read all you need to know before you do so!\nModern eBPF probe 👨‍🚀 Last quarter, Andrea published the blog, “Getting started with modern BPF probe in Falco,” and announced that the new experimental eBPF probe had landed among us bringing with it a few key features: CO-RE paradigm, BPF Ring Buffer map, BTF-enabled program, BPF global variables, BPF skeleton, and finally Multi-arch support.\nWhy a new probe? 👽 The old probe supported old kernels (\u0026gt;=4.14) that can not take advantage of the new shiny eBPF features. While it would be great to have only one probe that works for every kernel version, recent features change (and simplify!) the way we write, maintain and deploy the code so deeply that a new fresh probe is the most reasonable solution. In order to leverage these recent eBPF improvements and use the new probe you will need a kernel version \u0026gt;= 5.8.\nModern eBPF in action 🎬 Try it now!\nShiny new eBPF features ✨ Why are Falco maintainers and community members excited about the modern eBPF probe? There are quite a few features that you might be interested in! Some of our favorites are:\nCO-RE paradigm - stands for \u0026quot;Compile-once-run-everywhere\u0026quot;, so as you may imagine, this paradigm allows compiling the eBPF probe just once for all kernels! You understood well: NO MORE MISSING DRIVERS, and no more painful local builds requiring the much-loved KERNEL HEADERS.\nMulti-arch support - the modern BPF probe also supports multiple architectures by design. The actual targets for Falco are x86_64 and arm64 but new ones can be added at any time. If you have a project that needs BPF instrumentation for one of these architectures you could simply link the Falco libraries (libsinsp, libscap) to obtain a working solution out of the box.\nPerformance Improvements - the modern eBPF probe leverages features recently introduced in the Linux kernel such as BPF global variables and ring buffers to be faster and more efficient than the traditional eBPF probe!\nEven more ways of catching suspicious executions 🕵️‍♀️ Detecting when a suspicious new executable is spawned is often considered a crucial baseline detection. Generally speaking, detecting this kind of behavior and understanding when it is malicious is not an easy task. For this reason Falco has not one, but several features that can help defenders craft appropriate rules for their workflows.\nThanks to great contributions from Lorenzo Susini and Melissa Kilby (thanks for both the code contributions and the image above!) we have two more ways to check for suspicious executions in our Falco rules as we have the following new fields tied to process spawn (execve) events:\nproc.is_exe_upper_layer: which is true if the process’ executable is in the upper layer of the overlayfs. In practice, that means that the executable that is being launched has been introduced or modified in the container after it was started. While some applications might do this legitimately, in many cases it is a thing to watch out for because it might be signaling an attack in progress! Note that you can use this only on kernel versions greater or equal than 3.18.0, since overlayfs did not exist before then, and of course with container runtimes that make use of it as a union mount filesystem 😉. This flag complements proc.is_exe_writable, which is similar but only checks if the executable file is also writable by the same user that spawned it. Don’t think this is enough? Do you think you need more flags to get more accurate detections? Here’s the second group of fields:\nproc.exe_ino.ctime and proc.exe_ino.mtime: they show the last change time and modification time of the process’ executable file, respectively. proc.exe_ino.ctime_duration_proc_start and proc.exe_ino.ctime_duration_pidns_start: demonstrates the time difference, in nanoseconds, between the process ctime and when the process was actually spawned or when the PID namespace was created, respectively. I’m sure you can see why you could be interested in that. Launching executables that were just created could be something that you want to know about 😁. While the above signals won't replace the need to monitor file operation events, they can help reduce the search space for tracking spawned processes where for example chmod +x was run against the executable file on disk prior to execution (this causes ctime of inode to change, but we don't know if it was chmod related or a different status change operation). In addition, users could use these fields for selected rules to augment information available for incident response.\nArtifact distribution 📜 Automatic rules updates and other upcoming features would not be possible without a proposal aimed to create a unified management of the distribution of artifacts. The overall goals for this are:\nAllow users to consume artifacts in a consistent way Define official artifacts Unify distribution mechanism, infrastructure, and tooling Provide generic guidelines applicable to any artifact that is distributed The officially supported artifacts are a set of artifacts published by Falcosecurity and now are part of Falco and its ecosystem. Prior to release 0.34.0 the Falcosecurity organization distributed several kinds of artifacts in the form of files or container images, which included:\nInstallation packages Helm charts Drivers (eg, kmod, eBPF) Rule files Plugins Other kinds may be added in the future. Now, the new distribution channels include HTTP Distribution and OCI Distribution.\nWhat we accomplished ✅ Falco rules have their own repo now 🏠 The benefits of having rules living in their repository are:\nDedicated versioning Rules release will not be tied anymore to a Falco release (e.g., no need to wait for the scheduled Falco release to publish a new rule aiming to detect the latest published CVE) Consistent installation and update mechanism for other rulesets (plugins rules are already published in their repository and can be consumed by falcoctl) Rules are published as plain files as well as OCI artifacts at each release Check it out: https://github.com/falcosecurity/rules\nFalcoctl is official 😎 The falcoctl project was promoted to \u0026quot;Official\u0026quot; status, and its repository is now part of the core.\nWhat's Next? 🔮 It’s time to try out the new release! Here are some pointers for getting started with Falco:\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-no-driver (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package The community is active on many things and there is no shortage of great ideas for next releases!\nThanks to all the people who wrote and tried plugins, we have great feedback for the next version. If you are a plugin developer or user, stay tuned for more APIs and functionality!\nThe modern eBPF probe is awesome and we want to keep improving it to get it out of the experimental stage 🚀\nFalco maintainers also care a lot about the project’s own security. We’re exploring security-related considerations in the Falco Supply Chain Security Working Group. Join us if you can't wait to know more about this.\nStay Tuned 🤗 Join us in our communication channels and in our weekly community calls! It’s always great to have new members in the community and we’re looking forward to having your feedback and hearing your ideas.\nYou can find all the most up to date information at https://falco.org/community/.\nTill the next release! 👋\nLuca, Andrea, Teryl and Jacque\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.34.0 a.k.a. \"The Honeybee 🍯\"","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-34-0/"},{"category":"blog","content":"The Falcosecurity organization uses a GPG key for providing detatched signatures for the official Falco packages available at download.falco.org/?prefix=packages. After the security incident of CircleCI disclosed in January 2023, the Falco maintainers opted for rotating the organization's secrets and token stored in the platform. Although we have not found any evidence of unauthorized modification of the Falco packages or their signatures, the GPG key has still been rotated as a safety measure.\nAs of January 18th 2023, the old key with fingerprint 15ED 05F1 91E4 0D74 BA47 109F 9F76 B25B 3672 BA8F has been revoked. The GPG fingerprint of the new key is 2005 3990 02D5 E8FF 59F2 8CE6 4021 833E 14CB 7A8D. Please refer to the Falco installation guide for learn more about how the key can be used to verify the official packages.\nAction items for existing users Users not using package signature verification (enabled by default in most DEB and RPM systems) will be not affected.\nOtherwise, your should update the key as soon as you can to download its revocation certificate. The next step is to download the new key as documented in the Falco installation guide. All the Falco packages' signatures will be signed with the new key starting from January 18th 2023.\nThe old key should be considered invalid and signatures produced with it should be untrusted. The existing release package signatures available at download.falco.org/?prefix=packages have been updated by signing their relative packages with the new key.\nExample If you are installing Falco via the DEB packages, you may see an error similar to:\nW: GPG error: https://download.falco.org/packages/deb stable InRelease: The following signatures couldn\u0026#39;t be verified because the public key is not available: NO_PUBKEY 4021833E14CB7A8D E: The repository \u0026#39;https://download.falco.org/packages/deb stable InRelease\u0026#39; is not signed. To update it, add the new key from the installation instructions, i.e.:\napt-key del \u0026#34;15ED 05F1 91E4 0D74 BA47 109F 9F76 B25B 3672 BA8F\u0026#34; curl -s https://falco.org/repo/falcosecurity-packages.asc | apt-key add - apt-get update -y Action items for new users No action item is required for new users, simply follow the Falco installation guide to learn how to employ the package signature verification.\nContacts Do not hesitate to reach out to the Falco community and its maintainers for further clarifications.\nJoin our weekly community calls Meet the maintainers on the Falco Slack. Join the Falco mailing list Follow @falco_org on Twitter. ","summary":"","tags":["News"],"title":"The GPG key used to sign Falco packages has been rotated","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-packages-gpg-key-rotated/"},{"category":"blog","content":"So many good things happened for Falcosidekick and Falcosidekick UI this year. It's still incredible these projects became so beloved and useful for the community. To all contributors, promotors and users, a big big thank you.\nThe new year is there, it's time to release new versions and reach 10 million Docker pulls for Falcosidekick.\nFalcosidekick v2.27.0 What a huge release! Never has a previous release gotten so many new features and outputs. You can read the full changelog here.\nNew outputs This release brings a lot of new outputs thanks to our amazing contributors. Here you have a list of them.\nYandex Data Stream Yandex is a Russian cloud provider that provides various services such as Data Streams. With this new output, we can connect Falco to one more cloud providers. Thank you, preved911.\nMQTT and Node-Red IoT is a whole new world for Falco. With these 2 new outputs, Falco can make its first steps in this ecosystem and we are sure more will come in 2023. Stay tuned.\nZincsearch Do you want a full-text indexer lighter than Elasticsearch? Take a look at Zincsearch.\nGotify By using Gotify and the new dedicated output, you can now push Falco events to your Android phone.\nSpyderbat Are you a user of Spyderbat and want to extend its sources of events? Now you can thank spyder-kyle.\nTekton Do you remember the blog post how to create a Response Engine for Falco with Tekton? The proposed solution used the generic Webhook output. From now on, Tekton can use a dedicated one.\nTimescaleDB TimescaleDB is an OSS database made for time-series data, thanks to jagretti Falcosidekick can insert into it the Falco events.\nAWS Security Lake At re:Invent 2023, AWS announced a new data lake made for security data: AWS Security Lake. We worked with AWS teams to have Falco as a source partner from day one, making it the first OSS project that can be used with that service and strengthening once more the integration with the AWS ecosystem.\nNew features The list of new outputs is already quite long, but the list of enhancements is even longer. The full list is here, but let's have a look at the major changes.\nSASL auth mechanisms for SMTP and Kafka outputs Improving security is our duty to all, and one key element is the authentication method. Thanks to Lowaiz, both SMTP and Kafka outputs can now use the benefits of SASL Auth mechanisms.\nEnvironment variables for custom labels and templated labels The ability to inject custom fields in the payloads is an important feature of Falcosidekick. The only drawback was these fields were previously static. That limitation is over. Now, you can use environment variables in your custom fields. A new kind of custom fields has become available: `templated fields.' They allow the reuse of the present fields to generate new ones following with Go template:\ntemplatedfields: # templated fields are added to falco events and metrics, it uses Go template + output_fields values Dkey: \u0026#39;{{ or (index . \u0026#34;k8s.ns.labels.foo\u0026#34;) \u0026#34;bar\u0026#34; }}\u0026#39; Hostname field Since Falco 0.33, a new field is present in Falco events: hostname. Falcosidekick and all its current outputs are up to date and ready for it. Once again, thanks to Lowaiz.\nLoki format and Grafana Cloud The Loki format has been upgraded and credentials can be set. It allows you to use Grafana Cloud as a target.\nK8S Policy Reports are binded to the namespaces Policy Reports in K8S are still prototypes but Falcosidekick is already able to create them. Some improvements have been made to determine the target resource and the report is now created in the same namespace as the source pod.\nMore headers in SMTP payload To avoid being flagged as spam by some anti-spam systems, some headers like From, To and Date have been added to the emails created by Falcosidekick.\nCEF format Syslog For the Syslog output, you can choose between json and CEF as formats. It makes easier the integration with some services like Microsoft Sentinel or Splunk.\nFixes Even if we do our best to avoid them, the community has lately faced some bugs that we have fixed in this release.\nThe most important one was a race condition when headers were added to the POST requests. Adopters with high rates of requests were occasionally facing authentication failures or missing headers. bc-sb solved this with a temporary solution, but we'll improve it in the future (Falcosidekick v3? Who knows...).\nFalcosidekick UI v2.1.0 The new features for Falcosidekick UI, although lower in number, are still big improvements. The full changelog is here.\nEnv vars for settings All settings to configure Falcosidekick UI can be passed as either CLI arguments or as env vars. Run falcosidekick-ui --help for more details.\nNew logs The logs were too verbose for production contexts. Now it's configurable via a log-level option:\n-l string Log level: \u0026#34;debug\u0026#34;, \u0026#34;info\u0026#34;, \u0026#34;warning\u0026#34;, \u0026#34;error\u0026#34; (default \u0026#34;info\u0026#34;, environment \u0026#34;FALCOSIDEKICK_UI_LOGLEVEL\u0026#34;) Auto refresh Long-term adopters may remember the dashboard in Falcosidekick UI v1 was auto-refreshed. This feature is back, for all widgets, independently of the page.\nAuthentication This is a major new feature. The interface is now protected by the Basic Auth method. More methods will be added in the future:\nSet the FALCOSIDEKICK_UI_USER env var to define the credentials.\nInfo page The info page has been rewritten for a nicer look \u0026amp; feel.\nHostname As for Falcosidekick, Falcosidekick UI supports the display of the new hostname field.\nTTL for keys Falcosidekick UI can store a huge amount of events, leading to filling the disk of the Redis database. A TTL for the entries can be set to avoid this situation.\n-t int TTL for keys (default \u0026#34;0\u0026#34;, environment \u0026#34;FALCOSIDEKICK_UI_TTL\u0026#34;) Conclusion The respective Helm charts are already updated to allow you to test on your own all these great new features. Run a helm upgrade --reuse-values -n falco to do so.\nOnce again, thanks to all adopters and contributors who helped and contributed for years to create pieces of software useful to everybody. We hope 2023 will be amazing for Falco and its ecosystem.\nAs usual, if you have any feedback or need help, you can find us at any of the following locations.\nGet started in Falco.org Check out the Falcosidekick project on GitHub. Check out the Falcosidekick UI project on GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Release"],"title":"Falcosidekick 2.27.0 and Falcosidekick-UI 2.1.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-2-27-0-ui-2-1-0/"},{"category":"blog","content":"Dear Falco community,\nAs always, we are truly grateful for the amazing community of maintainers and contributors. The Falco project and community would not be the vibrant ecosystem it is today without these incredible individuals. Let’s take a look at what the community accomplished in 2022, and we’ll give a quick glimpse of what to expect in 2023!\nThank you to the Falco maintainers Falco would not be the same without these key individuals. They work hard to keep the project moving forward and the community engaged. On behalf of the Falco community, we want to extend a BIG thank you for all your dedication and hard work!\nAndrea Terzolo, Polytechnic of Turin Carlos Tadeu Panato Junior, Chainguard David Windsor, Secureworks Federico Di Pierro, Sysdig Frank Jogeleit, LOVOO Fred Araujo, IBM Grzegorz Nosek, Sysdig Hendrik Brueckner, IBM Jason Dellaluce, Sysdig Jonah Jones, Amazon Leonardo Di Donato, Independent Leonardo Grasso, Sysdig Logan Bond, Secureworks Loris Degioanni, Sysdig Luca Guerra, Sysdig Mark Stemm, Sysdig Massimiliano Giovagnoli, Clastix Mauro Ezequiel Moltrasio, RedHat Michele Zuccala, Sysdig Radu Andries, Independent Teryl Taylor, IBM Thomas Labarussias, Sysdig New and noteworthy in Falco land The Falco community was busy in 2022, figuring out how to better serve contributors, developing new features, fixing bugs, and taking the project to new heights. Here is a recap of key milestones reached this year:\nFalco’s governance underwent a facelift this year. Why is this important? As a CNCF project, Falco is committed to promoting a healthy community of contributors and maintainers from multiple vendors. In aid of this, the core maintainers formerly announced \u0026amp; published these updates to help contributors better serve the community. To read the full announcement, see updating Falco Governance. At the beginning of 2022, Falco introduced a game changing feature, Falco Plugins. They allow Falco to monitor and trigger alerts for any kind of event. Since the launch of the new plugin framework the Falco community has collaborated to create plugins for GitHub, AWS CloudTrail and Okta. A plugin also replaced the way Falco consumes the Audit Logs generated by a K8s API server. With these plugins, Falco covers more in depth the aspects of your infrastructure and allows you to use a single syntax for rules. Our adopters asked us for a way to monitor K8s Audit Logs and the previous implementation used an internal web server to receive the logs from the Kubernetes API. This method didn't support clusters managed by cloud providers, such as EKS, AKS, or GKE as they had to capture the Audit Logs for their own usage and then add them to their log aggregators. This situation is now solved thanks to the plugin framework and we're proud to have announced the first release of the plugin for EKS Audit Logs!!! Read the full blog here!\nFeeling terrorized by sneaky cryptominer programs? Falco is helping fight these monsters. Cryptominers are programs that utilize computer resources to mine cryptocurrency. XMRig is an example of an open source crypto mining software designed for the sole purpose of mining cryptocurrencies, like Monero or Bitcoin. Cryptominers usually get rewarded with a token for every successful transaction mined, which makes cryptomining a profitable activity.\nWhether an external entity, or an insider, cybercriminals are most commonly abusing services such as Kubernetes and GitHub actions by infecting hosts and containers with cryptojackers and using the business resources to mine cryptocurrency on the attacker's behalf. Learn how Falco detects cryptominers activity in your cluster.\nThe new eBPF probe landed among us 👽 this fall with new shiny features. The eBPF world grows continuously and every new kernel release introduces some unbelievable novelties! To take advantage of these the community created a completely new architecture, new BPF programs and maps. The main goal was to improve performance, maintainability, and user experience, shipping a unique, powerful, self-contained Falco executable. Discover the modern world of eBPF with Falco, read the full blog here.\nAt re:Invent 2022, it was a pleasure to announce that Falcosidekick would be available with preview integration for Amazon Security Lake, a new service that optimizes and centralizes security data from cloud, on-premises, and custom sources into a purpose-built data lake. Falcosidekick forwards Falco events into other services: the new integration exports security events using the Open Cybersecurity Schema Framework (OCSF) format, an open industry standard, and sends them directly to Amazon Security Lake. This makes it easier to normalize and combine Falco events with other security data sources. You can check out the integration in the next version of Falcosidekick, 2.27.0. Read the full announcement, Support for Amazon Security Lake.\nAs the home of such important assets, GitHub repositories should be at the top of your list of security priorities. However, many people fail to put in place even basic measures to protect source code repositories. Read about three risks to GitHub repos and how you can reliably detect them, as they happen, using Falco open source security.\nBefore 0.32.1, Falco could not work with gVisor monitored sandboxes because it was not possible to install a kernel module or eBPF probe in such an environment. But wouldn't it be great to leverage the stream of system call information that gVisor collects through its powerful monitoring system directly in Falco? This is exactly what became possible with gVisor release 20220704.0 and Falco 0.32.1. Learn how to integrate gVisor and Falco on Docker.\nWith Falco 0.32.1, you can now run Falco on Apple ARM M1 CPUs. It requires a Linux virtual machine (VM) since Falco doesn't run on OSX, but it is pretty straightforward. Here are the step by step instructions.\nDifferent technologies are used on a daily basis, and tools like Vagrant, Terraform, Ansible, plus many more allow us to create and destroy digital resources in a matter of minutes, if not seconds. However, if you keep changing your running environment, you might need to calibrate your workloads to these new changes. This is especially true when you deploy operating system-dependent applications. In other words, every time you deploy an application like Falco there's a chance that you need to compile a new module or eBPF probe to get along with the current underlying kernel. This is the first of a series of posts introducing some interesting techniques using Falco to generate the much needed driver and how you can make it available for your deployments. Learn how to build your own Falco Drivers for Debian.\nGiant Swarm simplifies the maintenance of the software stack within Kubernetes clusters by using its App Platform technology. Leverage this to easily deploy Falco, either individually or as part of Giant Swarm's Security Pack, to secure a managed Kubernetes service. Learn how to deploy and manage applications across hybrid environments.\nCore releases The Falco release process has been well-defined with a fixed schedule of three releases per year (roughly at the end of Jan, May, and Sept), plus patch releases that can occur when needed upon agreement by maintainers (for example, for hotfixes or security patches). Here are the three major releases for 2022:\nFalco 0.31.0 a.k.a. \u0026quot;the Gyrfalcon\u0026quot; released in January 2022. Why did we call it the Gyrfalcons release? Well, the Gyrfalcons are the largest of the falcon species, just like this version of Falco, which had the biggest changelog ever released.The falco and libs repositories counted 30+ individual contributors, 130+ pull requests, and 360+ commits 🤯.\nFalco 0.32.0 release in June 2022. This new release came with a ton of inner rework. Here is the foremost important change: Lua is no more a dependency of Falco! Basically, the Falco rule loader was rewritten in C++, to achieve better performance. Moreover, the entire rule engine has been rewritten too. This reduced the workarounds in Falco, and is now fully using libsinsp-provided filter parsers and compiler. Moreover, a new --list-syscall-events CLI option is now available.\nFalco 0.33.0 a.k.a. \u0026quot;the pumpkin release 🎃\u0026quot; made available October 2022. For v0.33.0 the community focused on addressing the following updates \u0026amp; changes:\nLibs now allow individual selection of which syscalls to collect during live captures, which helps Falco improve performance and reduce dropped events Introduced the Kernel Crawler, a new tool that automatically identifies the most up to date kernel versions supported by popular distros Syscall kernel ring-buffer size is now customizable for your environment needs Mitigations for libsinsp’s Kubernetes metadata client to address recent issues that caused Falco to crash Support for multiple simultaneous event sources, which means that you can now run multiple event sources in the same Falco instance Added minikube as a supported platform in the driver loader and included it in our driver build matrix Rule alert rate limiter is now optional and disabled at default Support for two new syscalls and many improvements to the default Falco security ruleset Falcosidekick \u0026amp; UI Falcosidekick is a little daemon that extends a number of possible outputs, and since its creation this little guy has evolved in many amazing ways. A big thank you to Thomas Labarussias for driving the development of Falcosidekick and the UI. Here is how the project evolved in 2022:\nFalcosidekick saw a major update in June of 2022, delivering four new outputs and enhancing existing ones too! Not only did we see updates in outputs, but the community delivered the first version of the Falcosidekick UI. The UI offered these new features: Redis DB for long term storage of events, API for counting and searching for events, and lastly filters to keep and share query strings. For a full detailed account of this update, see the blog Falcosidekick 2.25.0 and Falcosidekick 2.0.0.. Plugins Falco v0.31.0 resulted in many exciting new features. One that is particularly strategic for the project is the general availability of the plugins framework. Why are plugins exciting and what do they mean for the future of Falco?\nPlugins are shared libraries that can be loaded by Falco to extend its functionality. Plugins can currently implement two capabilities:\nThe event sourcing capability, which add new data sources to Falco. They produce input events, from either the local machine or a remote source, that Falco can understand. The field extraction capability, which parse the data coming from source plugins and expose new fields that can be used in Falco rules. By supporting one or both capabilities, plugins allows users to feed data into Falco, parse it in useful ways and create rules and policies from it, read the full announcement here!\nOfficial plugins launched in 2022 include:\nAWS CloudTrail GitHub K8saudit K8saudit-EKS Okta Falco project growth The Falco project excitedly announced that on Nov 4, 2022, project maintainers submitted the proposal to be considered for graduation. This milestone is important because it demonstrates the health and maturity of the project to the Kubernetes \u0026amp; cloud ecosystem.\nFalco joined the CNCF as a Sandbox project in the fall of 2018 and evolved into Incubating status two years later. The community believes the next natural step is for Falco to apply for graduation. The project has reached maturity in community health, diversity of contributions \u0026amp; contributors, and ecosystem adoption.\nProject highlights for 2022 Github stars: + 31% Core repo contributors: +65% Forks: +46% Slack channel members: +126% Downloads: 41.7M Docker hub pulls (25% growth) 1.2M AWS ECR New features in Falco The most significant additions since acceptance for Incubation include:\nStable release schedule Contribution of the whole libs source code into the Falcosecurity organization Plugin framework, allowing event sources other than syscalls New eBPF probe gVisor integration Thank you to all of the contributors and maintainers of the Falco project. The project would not be where it is today without the help and dedication of these key individuals.\nWishing you a happy 2023,\nJacque\n","summary":"","tags":["Community"],"title":"Falco: Project Recap 2022","url":"https://v0-43--falcosecurity.netlify.app/blog/recap-2022/"},{"category":"blog","content":"Cryptominers are programs that utilize computer resources to mine cryptocurrency. XMRig is an example of an open source cryptomining software designed for the sole purpose of mining cryptocurrencies, like Monero or Bitcoin. Cryptominers usually get rewarded with a token for every successful transaction mined, which makes cryptomining a profitable activity.\nWhether the threat is from an external entity, or an insider, cybercriminals are most commonly abusing services such as Kubernetes and GitHub actions by infecting hosts and containers with cryptojackers and using the business resources to mine cryptocurrency on the attacker's behalf.\nDetecting Mining Pools Assuming the cybercriminal has already compromised your environment and installed the XMRig miner, they will need to communicate with a cryptocurrency mining pool to distribute the resources by miner, share the processing power over a network, and split the reward equally, according to the amount of work they contributed to the probability of finding a block.\nSource: Compass Mining\nThe mining pool is a collection of miners that work together to augment their chances of mining a block, sharing rewards among each other in proportion to the computing power contributed in successfully mining a block. There are lots of pools to choose from. You can find a list at miningpoolstats.stream/monero.\nLists By default, Falco creates a list of all common pool domains used for Monero mining. The below YAML file shows how the list defines all domains as list items.\n- list: miner_domains items: [ \u0026#34;asia1.ethpool.org\u0026#34;,\u0026#34;ca.minexmr.com\u0026#34;, \u0026#34;cn.stratum.slushpool.com\u0026#34;,\u0026#34;de.minexmr.com\u0026#34;, \u0026#34;eth-ar.dwarfpool.com\u0026#34;,\u0026#34;eth-asia.dwarfpool.com\u0026#34;, \u0026#34;eth-asia1.nanopool.org\u0026#34;,\u0026#34;eth-au.dwarfpool.com\u0026#34;, … ] For the purpose of accuracy, we can define separate lists for HTTP domains as well as HTTPS domains.\n- list: https_miner_domains items: [ \u0026#34;ca.minexmr.com\u0026#34;, \u0026#34;cn.stratum.slushpool.com\u0026#34;, \u0026#34;de.minexmr.com\u0026#34;, \u0026#34;fr.minexmr.com\u0026#34;, … ] list: http_miner_domains items: [ \u0026quot;ca.minexmr.com\u0026quot;, \u0026quot;de.minexmr.com\u0026quot;, \u0026quot;fr.minexmr.com\u0026quot;, \u0026quot;mine.moneropool.com\u0026quot;, … ] Another list contains all port numbers that are commonly used by the cryptominer at the source. There's no need for users to create the lists or macros. They are enabled by the default Falco rules.\n- list: miner_ports items: [ 25, 3333, 3334, 3335, 3336, 3357, 4444, 5555, 5556, 5588, 5730, 6099, 6666, 7777, 7778, 8000, 8001, 8008, 8080, 8118, 8333, 8888, 8899, 9332, 9999, 14433, 14444, 45560, 45700 ] Macros Similar to the lists mentioned above, the following macros are already created. The macros define the ports used to connect to the mining domains - whether HTTP (unsecure) domains or HTTP/s (secure) domain names. The HTTP/s domain connects over port 443. Unencrypted HTTP connections are made over port 80.\n- macro: minerpool_https condition: (fd.sport=\u0026#34;443\u0026#34; and fd.sip.name in (https_miner_domains)) macro: minerpool_http condition: (fd.sport=\u0026quot;80\u0026quot; and fd.sip.name in (http_miner_domains)) Falco assigns all commonly used miner ports to the miner domains via the minerpool_other macro.\n- macro: minerpool_other condition: (fd.sport in (miner_ports) and fd.sip.name in (miner_domains)) The field fd.sport (File Descriptor - Port) could match any port listed in the miner_ports macro, while the field fd.sip (File Description - IP name) would match any domain listed within the miner_domains macro.\nFalco Rule The final rule will aim to detect anything matching the condition described by the net_miner_pool macro, unless it's listed within the trusted_images_query_miner_domain_dns macro. Both macros are specified within the condition section of the completed Falco rule.\n- rule: Detect outbound connections to common miner pool ports desc: Miners typically connect to miner pools on common ports. condition: \u0026gt; net_miner_pool and not trusted_images_query_miner_domain_dns enabled: false output: \u0026gt; Outbound connection to IP/Port flagged by https://cryptoioc.ch (command=%proc.cmdline pid=%proc.pid port=%fd.rport ip=%fd.rip container=%container.info image=%container.image.repository) priority: CRITICAL tags: [network, mitre_execution] The rule is disabled by default. However, to enable this Falco rule you simply need to change the condition enabled: false to enabled: true.\nMacro net_miner_pool The following macro is looking at any event type such as connections made or message data sent to the macros: minerpool_http, minerpool_https, or minerpool_other that were mentioned earlier in the blog.\n- macro: net_miner_pool condition: \u0026gt; (evt.type in (sendto, sendmsg, connect) and evt.dir=\u0026lt; and (fd.net != \u0026#34;127.0.0.0/8\u0026#34; and not fd.snet in (rfc_1918_addresses)) and ((minerpool_http) or (minerpool_https) or (minerpool_other))) Macro trusted_images_query_miner_domain_dns The below macro is created simply to exclude Falco images from detection. The rule will use it to exclude known Falco images from Docker registry or from the public Elastic Container Registry (ECR).\n- macro: trusted_images_query_miner_domain_dns condition: \u0026gt; (container.image.repository in (docker.io/falcosecurity/falco, falcosecurity/falco, public.ecr.aws/falcosecurity/falco)) Detecting Stratum Protocol Miners typically specify the mining pool to connect with a URI that begins with stratum+tcp. That's because Stratum is a line-based protocol using a plain TCP socket. The message payload is encoded as JSON-RPC. The protocol was designed specifically for mining operations. Therefore, it makes sense to detect scenarios where a client opens a TCP socket and writes requests using the Stratum protocol. For more information on the new protocol designed for bitcoin mining, check out this link.\nFalco Rule The following rule quickly shows how to detect the Stratum protocol. There's no need for any complex macros this time around. The already existing macro spawned_process watches for newly started processes, while the rest of the rule looks for a string on command, such as:\nstratum+tcp stratum2+tcp stratum+ssl stratum2+ssl - rule: Detect crypto miners using the Stratum protocol desc: \u0026gt; Miners typically specify the mining pool to connect to with a URI that begins with \u0026#39;stratum+tcp\u0026#39; condition: \u0026gt; spawned_process and (proc.cmdline contains \u0026#34;stratum+tcp\u0026#34; or proc.cmdline contains \u0026#34;stratum2+tcp\u0026#34; or proc.cmdline contains \u0026#34;stratum+ssl\u0026#34; or proc.cmdline contains \u0026#34;stratum2+ssl\u0026#34;) output: Possible miner running (command=%proc.cmdline pid=%proc.pid container=%container.info image=%container.image.repository) priority: CRITICAL tags: [process, mitre_execution] Macro The spawned_process macro is easy to understand. It's basically just looking for the event types execve and/or execveat in any event directory.\n- macro: spawned_process condition: (evt.type in (execve, execveat) and evt.dir=\u0026lt;) Github Actions with Miners Cryptomining detection shouldn't be limited to just your local endpoints, VMs, or EC2 hosts. GitHub Actions has unfortunately been actively abused in recent months to mine cryptocurrency on GitHub servers. Falco's GitHub plugin can detect potential miners abusing GitHub actions.\nFalco Rule The condition filters for webhook messages of type workflow_run that point to the execution of miners. github.workflow.has_miners is the main action to highlight. It fetches the workflow's definition file and scans it line by line, looking for patterns that identify the execution of one of the well-known miner binaries.\n- rule: Github action with miners desc: a github action containing crypto miners was executed condition: \u0026gt; github.type=workflow_run and github.action=requested and github.workflow.has_miners=true output: \u0026gt; a github action containing crypto miners was executed (repository=%github.repo repo_owner=%github.owner org=%github.org user=%github.user file=%github.workflow.filename) priority: CRITICAL source: github Within github.workflow.miners.type, we can specify one or more miners to be detected within the workflow definition file. This field contains the type of each detected miner as a comma separated list (e.g., XMRig, Stratum). Looking further into the miners.go file, we can see the exact list of miner binaries checked:\nvar minersChecks = []string{ \u0026#34;xmrig\u0026#34;, \u0026#34;ccminer\u0026#34;, \u0026#34;t-rex\u0026#34;, \u0026#34;stratum\u0026#34;, \u0026#34;pool\u0026#34;, \u0026#34;hashrate\u0026#34;, \u0026#34;cryptonight\u0026#34;, \u0026#34;wallet\u0026#34;, … } As you can see from the above list, it includes the strings for the crypto wallet, the crypto-mining pool, and the miners, such as xmrig and ccminer.\nSet setuid or setgid bit When the setuid or setgid bits are set for an application, this means that the application will run with the privileges of the owning user or group respectively. In the case of cryptojacking, the hacker will want to have root permissions over the running containerized workloads in order to install the XMRig binary. That's why it's important to detect setuid or setgid bits set via chmod.\nFalco Rule - rule: Set Setuid or Setgid bit desc: \u0026gt; When the setuid or setgid bits are set for an application, This means that the application will run with the privileges of the owning user or group respectively. Detect setuid or setgid bits set via chmod condition: \u0026gt; chmod and (evt.arg.mode contains \u0026#34;S_ISUID\u0026#34; or evt.arg.mode contains \u0026#34;S_ISGID\u0026#34;) and not proc.name in (user_known_chmod_applications) and not exe_running_docker_save and not user_known_set_setuid_or_setgid_bit_conditions enabled: false output: \u0026gt; Setuid or setgid bit is set via chmod (fd=%evt.arg.fd filename=%evt.arg.filename mode=%evt.arg.mode user=%user.name user_loginuid=%user.loginuid process=%proc.name command=%proc.cmdline pid=%proc.pid container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag) priority: NOTICE tags: [process, mitre_persistence] Similar to the mining pool example, the rule is disabled by default. To enable it within the rule engine, simply change the enabled flag to enabled: true.\nIn Linux systems, processes can receive a variety of signals, such as SIGINT or SIGKILL.\nThe SIGINT signal is sent to a process by its controlling terminal when a user wishes to interrupt the process. This is typically initiated by pressing Ctrl-C, but on some systems, the \u0026quot;delete\u0026quot; character or \u0026quot;break\u0026quot; key can be used. The SIGKILL signal is sent to a process to cause it to terminate immediately (kill). If XMRig is run as root, but the SIGINT caller must also be running as root if the adversary plans on interrupting/pausing their operations to evade detection.\nAs a result, the adversary will need to give themselves root permissions by setting their User ID (SetUID) or Group User ID (SetGID) to root. Detecting changes to SetUID or SetGID bit is a clear indication of compromise, and we should look to prevent users (whether internal or adversarial) from giving themselves root permissions. Without root permissions, the adversary cannot operate XMRig effectively. The SetUID/SetGID Falco rule is in the rule engine, but disabled by default.\nContainer Drift Detection As mentioned at the beginning of this blog, Kubernetes is an ideal target for cryptojacking - hijacking of legitimate running workloads/applications. To detect when an XMRig binary is installed, we can apply drift detection to containers at runtime.\nFalco Rule - rule: Container Drift Detected (open+create) desc: New executable created in a container due to open+create condition: \u0026gt; evt.type in (open,openat,openat2,creat) and evt.is_open_exec=true and container and not runc_writing_exec_fifo and not runc_writing_var_lib_docker and not user_known_container_drift_activities and evt.rawres\u0026gt;=0 enabled: false output: Drift detected (open+create), new executable created in a container (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline pid=%proc.pid filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode event=%evt.type) priority: ERROR Generally speaking, attackers would look to install the XMRig miner in the /tmp directory. However, the above Falco rule will detect when executables are created in the container (regardless of the directory). From a forensics perspective, we will receive a Falco notification that tells us which executable was installed and to which directory.\nDetect the XMRig Binary We have provided multiple ways to detect the XMRig binary, whether that be through container drift when installing XMRig, outbound connections to mining pools coming from XMRig, or when file permissions are changed to root for XMRig.\nThe final rule, although not in the rules library by default, is to simply detect the XMRig binary outright - not based on behavior, just the binary name.\nCustom Falco Rule - rule: Malicious binary detected desc: \u0026gt;- Malicious script or binary detected in pod or host. The rule was triggered by the execve syscall. condition: \u0026gt; spawned_process and (in_malicious_binaries or (proc.name in (shell_binaries) and scripts_in_or and not proc.args startswith \u0026#34;-c\u0026#34;)) output: \u0026gt;- Malicious binary or script executed in the pod or host. proc.cmdline=%proc.cmdline evt.type=%evt.type evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath user.uid=%user.uid user.loginuid=%user.loginuid user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid group.name=%group.name container.id=%container.id container.name=%container.name %evt.args priority: warning source: syscall The above Falco rule detects when a malicious script or binary is detected in a pod or host. The rule is triggered by the execve syscall. The rule looks for any spawned process via the spawned_process macro. As mentioned earlier, the spawned_process macro looks for the execve syscall.\nLeveraging lists and macros again, to detect the XMRig binary, security teams can manually specify XMRig and other relevant binaries in a malicious_binaries list, and place it within the in_malicious_binaries macro.\nMacro - macro: in_malicious_binaries condition: (proc.name in (malicious_binaries)) macro: scripts_in_or condition: (proc.args endswith \u0026quot;/wb.sh\u0026quot; or proc.args endswith \u0026quot;/ldr.sh\u0026quot; or proc.args endswith \u0026quot;aktualisieren.sh\u0026quot; or proc.args endswith \u0026quot;creds.sh\u0026quot; or proc.args endswith \u0026quot;cronb.sh\u0026quot; or proc.args endswith \u0026quot;abah1.sh\u0026quot; or proc.args endswith \u0026quot;/huh.sh\u0026quot; or proc.args endswith \u0026quot;ohshit.sh\u0026quot; or proc.args endswith \u0026quot;/mxr.sh\u0026quot;) List - list: malicious_binaries items: [ \u0026#34;xmrig\u0026#34;, \u0026#34;.x1mr\u0026#34;, \u0026#34;kill_miner\u0026#34;, \u0026#34;titcoind\u0026#34;, \u0026#34;nanominer\u0026#34;, \u0026#34;pwnrig\u0026#34;, \u0026#34;ccminer\u0026#34; ] The above list provides more binaries than just ‘XMRig.’ As new miners become available, users can add those binaries to their malicious_binaries list.\nConclusion The monetary gain of mining cryptocurrency is a motivation for threat actors to compromise the endpoints of unsuspecting users and use them for illegitimate mining activities.\nThe endpoints are usually part of a botnet that is being controlled by a Command and Control (C2) server. Aside from the rules listed above, Falco can also detect unwanted outbound connections to C2 servers, as well as other IoC's that could indicate a potential incident before the mining has begun.\nThe mode of initial access for threat actors may be through compromised SSH credentials or the exploitation of a vulnerability. Once the threat actor has gained remote access to the endpoints, the cryptomining software is executed on it. Being able to detect suspicious activity, such as Disallowed SSH connections on a Linux server, is critical for your incident response and forensics teams.\nIf you would like to find out more about Falco:\nGet started in falco.org. Read the official documentation. Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":null,"title":"Cryptomining Detection Using Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-detect-cryptomining/"},{"category":"blog","content":"The new BPF probe has landed among us 👽 and it brings to the table new shiny features. The BPF world grows continuously and every new kernel release introduces some unbelievable novelties!\nTo take advantage of these we have created a completely new architecture, new BPF programs and maps. The main goal is to improve performance, maintainability, and user experience, shipping a unique, powerful, self-contained Falco executable. (... Oops, I said too much but don't burn the steps, first things first.)\nWhat's new 🗞️ We wouldn't be able to cover all the details here so we will just go through the most outstanding features. If you are interested in technical aspects you can always take a look at the proposal merged upstream some months ago with its corresponding discussion.\nCO-RE paradigm Portability is one of the biggest issues we have with the current BPF driver. Our infrastructure tries to compile a BPF probe for every supported kernel since version 4.14! As you can imagine, this is not a simple task, and it causes some pain to both, users and maintainers. For this reason, the Falco maintainers have been working hard to adopt the so-called CO-RE paradigm.\nCO-RE stands for \u0026quot;Compile-once-run-everywhere\u0026quot;, so as you may imagine, this paradigm allows compiling the BPF probe just once for all kernels!\nYou understood well: No more missing drivers, and no more painful local builds requiring the much-loved KERNEL HEADERS.\nBPF Ring Buffer map Today, whenever a BPF program needs to send data to userspace, it first copies it into a BPF map, and then it pushes its content to a shared buffer located between userspace and kernel: The so-called perf-buffer.\nThis solution works great, but it has two major shortcomings that prove to be inconvenient in practice: Inefficient APIs and extra data copying.\nThe ring buffer can be considered an evolution of the perf buffer. We still use a shared buffer but with some advantages.\nFirst, the APIs to interact with are more efficient. Second, and more importantly, we now have the possibility of writing data directly into this shared buffer, without having to write it twice!\nThis is a game changer in scenarios where high throughput is required, like running Falco, since it could save many cycles during the collection phase.\nBTF-enabled program Kernel engineers recently introduced a sort of debugging information for BPF programs/maps. This is called BTF and stands for \u0026quot;BPF Type Format\u0026quot;. This feature shook the foundations of the BPF world because it finally offers the possibility to write code without BPF helpers like the famous bpf_probe_read().\nThis will not only increase the readability of the BPF code but will also reduce the bytecode dimension, allowing the crafting of smaller and more efficient programs!\nBPF global variables The addition of global variables points in the same direction as BTF: Simplify the code experience, increase the readability and reduce the performance overhead due to BPF helpers.\nWhile BTF allows to deference kernel pointer without the use of the bpf_probe_read() helper, global variables allow to access BPF maps without the use of helpers like bpf_map_lookup_elem().\nYou can find further technical information about these 2 new features in the probe proposal.\nBPF skeleton Do you remember when we talked about Falco being a self-contained binary?\nWell the BPF skeleton concept allows us to achieve the dream: Ship Falco as a unique, self-contained executable!\nUnder the hood, the probe is compiled once into Falco when the package is built. Hence, when you deploy Falco on different machines it will automatically inject the code without any extra effort on your side. Hard to believe? Try it here.\nMulti-arch support The modern BPF probe also supports multiple architectures by design. The actual targets are x86_64, arm64, and s390x, but new ones can be added at any time.\nIf you have a project that needs BPF instrumentation for one of these architectures you could simply link the Falco libraries (libsinsp, libscap) to obtain a working solution out of the box. We would to thank Hendrik Brueckner for the huge help he gives in reviewing and implementing the multi-arch support!\nAt this moment, we ship Falco for x86_64 and arm64 architectures only, due to their popularity in the community.\nRequirements ⛓️ To use the modern BPF probe, there are 2 main requirements:\nA kernel that implements all the aforementioned features. Linux kernel version 5.8 is the first kernel that supports all of them, and for this reason, we consider it the minimum required one.\nNevertheless, these features could also be backported into older kernels, so it wouldn't be completely fair to define the 5.8 as the first supported version. This is just a strict assumption that we put in place since we still miss the logic to detect all the necessary features of your kernel.\nUntil that day arrives, if your kernel is older than 5.8, you might find the following error when trying to start the modern probe:\nError: Actual kernel version is: \u0026#39;5.4.0\u0026#39; while the minimum required is: \u0026#39;5.8.0\u0026#39; A kernel that exposes BTF types. This shouldn't be a big issue since we already require a kernel version newer than 5.8 and most recent Linux distributions come with kernel BTF capabilities.\nIf you want to be sure you can easily check their presence by typing:\nls /sys/kernel/btf/vmlinux If your kernel supports them you should see:\n/sys/kernel/btf/vmlinux Now, if your machine satisfies these 2 requirements, you are ready to have fun with the modern probe! 🚀\nModern BPF in action 🏎️ Falco provides you with pre-release packages to try the modern BPF probe, but the full release will take place in Falco 0.34.\nIf you happen find some bugs or misbehaviors, please be kind with us and open an issue on Falco 🙏\nHaving said that, you have 3 main ways to try Falco with the modern probe.\n1. Pre-built deb, rpm packages You can find here the x86_64 packages and here the arm64 ones.\nTaking as an example the deb package, you have simply to download it and type the following command:\nsudo dpkg -i \u0026lt;your_deb_package.deb\u0026gt; Now there are 2 possibilities:\nIf you have the dialog binary installed on your system you should see a dialog window like this (the dialog is a new feature that will be regularly shipped in Falco 0.34 for all the drivers!): You have simply to choose the \u0026quot;Modern eBPF\u0026quot; option.\nIf you don't have dialog installed, you must start the service manually: sudo systemctl start falco-modern-bpf.service Typing sudo systemctl status falco-modern-bpf.service should either way show you a similar output to:\nNov 15 14:50:46 ip-172-31-13-74 systemd[1]: Started Falco: Container Native Runtime Security with modern ebpf. Nov 15 14:50:46 ip-172-31-13-74 falco[1587330]: Falco version: 0.32.1-291+5d1b0c5 (x86_64) Nov 15 14:50:46 ip-172-31-13-74 falco[1587330]: Falco initialized with configuration file: /etc/falco/falco.yaml Nov 15 14:50:46 ip-172-31-13-74 falco[1587330]: Loading rules from file /etc/falco/falco_rules.yaml Nov 15 14:50:46 ip-172-31-13-74 falco[1587330]: Loading rules from file /etc/falco/falco_rules.local.yaml Nov 15 14:50:46 ip-172-31-13-74 falco[1587330]: The chosen syscall buffer dimension is: 8388608 bytes (8 MBs) Nov 15 14:50:46 ip-172-31-13-74 falco[1587330]: Starting health webserver with threadiness 8, listening on port 8765 Nov 15 14:50:46 ip-172-31-13-74 falco[1587330]: Enabled event sources: syscall Nov 15 14:50:46 ip-172-31-13-74 falco[1587330]: Opening capture with modern BPF probe 2. Tar archive You can download here the x86_64 tar.gz and here the arm64 one.\nHere the procedure is very simple, you can extract the contents of the archive and execute the Falco binary:\ntar -xvf \u0026lt;targz_package.tar.gz\u0026gt; cd \u0026lt;untar_folder\u0026gt; sudo ./usr/bin/falco --modern-bpf -c ./etc/falco/falco.yaml -r ./etc/falco/falco_rules.yaml Please note: The command line option required to run Falco with the modern BPF probe is --modern-bpf\n3. Docker image In an environment where you can start containers, you can simply use the docker images from DockerHub:\n# x86_64 docker pull andreater/falco-modern-x86:latest docker run --rm -i -t \\ --privileged \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /proc:/host/proc:ro \\ andreater/falco-modern-x86:latest # arm64 docker pull andreater/falco-modern-arm64:latest docker run --rm -i -t \\ --privileged \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /proc:/host/proc:ro \\ andreater/falco-modern-arm64:latest Please note: The helm chart is not available yet since this is a pre-release but it will be shipped as expected with Falco 0.34\nCurrent syscall support ⏲️ The modern BPF probe doesn't yet support all the syscalls supported by the current probe. It only supports the \u0026quot;simple consumer set\u0026quot;, which means that we support all the syscalls necessary to run Falco without -A option, also known as the default Falco mode. At the moment, adding the -A flag wouldn't have any further effect.\nHere you can find the complete list of syscalls currently supported by the modern probe.\nThe good news is that we are actively working to include all the syscalls supported by the current probe 💥\nNext steps 🔮 Release Falco 0.34 with the modern probe as an experimental feature. Reach the full support of syscall. Introduce new points of instrumentation like LSM hooks to collect security events. Falco and modern BPF at eBPF summit 🐝 If you want to know more about how the modern BPF probe works under the hood take a look at the eBPF summit presentation.\n","summary":"","tags":["eBPF"],"title":"Getting started with modern BPF probe in Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-modern-bpf/"},{"category":"blog","content":"It's Amazon Web Services' largest user conference this week, re:Invent, which is a good time to highlight the ways you can use Falco in the AWS Cloud for runtime security. In this article we'll review what's new, and take a look at installation, plugins, and integrations for AWS.\nSupport for Amazon Security Lake We're pleased to announce that Falcosidekick will shortly be available with preview integration for Amazon Security Lake, a new service that optimizes and centralizes security data from cloud, on-premises, and custom sources into a purpose-built data lake.\nFalcosidekick is designed to forward Falco events into other services: the new integration exports security events using the Open Cybersecurity Schema Framework (OCSF) format, an open industry standard, and sends them directly to Amazon Security Lake. This makes it easier to normalize and combine Falco events with other security data sources. You can check out the integration in the next version of Falcosidekick, 2.27.0.\nInstallation and drivers You can find Falco and Falcosidekick as container images through the Amazon ECR Registry:\nFalco image. Falcosidekick image. Additionally, the Falco project publishes pre-built driver modules for AWS kernels, whether you are using the kernel module driver or the eBPF probe. These can be fetched using falco-driver-loader.\nReview the available drivers:\neBPF probes for AWS Kernel modules for AWS The prebuilt modules are available for both x86_64 and aarch64 architectures.\nPlugins Falco plugins let you use event sources other than kernel syscalls. Falco has two plugins specific to AWS.\nThe CloudTrail plugin can read AWS CloudTrail logs and emit events for each CloudTrail log entry. It includes out-of-the-box rules that can be used to identify potential threats in CloudTrail logs, including: Console logins that do not use multi-factor authentication. Disabling multi-factor authentication for users. Disabling encryption for S3 buckets. Falco has extended its capability to read Kubernetes audit logs through a plugin for CloudWatch, where it can read the EKS audit logs. Read more about configuration and usage. Falcosidekick integrations Falcosidekick lets you forward events from Falco into a variety of different services, including many on AWS.\nCloudwatch Logs: emit events into a CloudWatch log stream. S3: add events in JSON format to an S3 bucket. Lambda: invoke a Lambda function in response to a Falco event. SQS: send a message into an SQS queue. SNS: create a push notification to apps or people. Kinesis: send Falco events as streaming data. Amazon Security Lake: add Falco events to a security data lake. Conclusion Falco offers a wide variety of support for runtime security on the AWS cloud. As we are an open source project, we welcome contributions and feedback! Read more about running Falco on AWS from this AWS Security blog post, Continuous runtime security monitoring with AWS Security Hub and Falco.\nYou can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or even for a friendly chat!\nIf you would like to find out more about Falco:\nGet started in Falco.org Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter ","summary":"","tags":["Falco","Cloud"],"title":"Falco on AWS Cloud","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-on-aws/"},{"category":"blog","content":"Today we announce the release of Falco 0.33.1 🦅!\nNovelties 🆕 and Fixes 🐛 Here's a tiny patch release! It only fixes two bugs reported by the community:\nCrashLoopBackOff in some cases when the gVisor integration is enabled on Kubernetes (reported on Minikube and some versions of GKE) Crash when the eBPF probe is used and one or more CPUs are switched off. Thanks FedeDP! Thanks to everyone who reported and worked on issues!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nTry it! 🏎️ As usual, in case you just want to try out the stable Falco 0.33.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader What's next 🔮 So many great things are happening in the Falco community right now. After meeting our friends at KubeCon NA, we're back at work with new features for the upcoming 0.34.0 release coming early 2023 with an unbelievable amount of work being done in the new eBPF probe, enhancements to falcoctl to make management of rules and plugins easier and much more!\nLet's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nEnjoy 🎉\nLuca\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.33.1","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-33-1/"},{"category":"blog","content":"I’m Hiroki Akamatsu (@hi120ki), an intern on Mercari’s Security Engineering Team. During my internship, I worked on the re-evaluation of Falco, runtime security monitoring tools for Kubernetes.\nThis article presents the following findings from the evaluation.\nFindings of attack methods missing from the Threat matrix for Kubernetes published by Microsoft. Contribution to the attack detection rules in Falco Understanding Falco detection evasion methods and countermeasures Understanding the Effectiveness and Limitations of Falco Attack Detection Introduction to Falco, Falco, and scope of tasks Falco is an open source software that collects system calls (syscalls) executed by the kernel module or eBPF and detects attacks according to predefined rules. Rules managed as open source are published in the Falco rules repository on GitHub, and can detect access to critical files, suspicious program execution, and network access based on these rules.\nFalco collects syscalls on the kernel, so it can collect activities executed by processes on containers. Therefore, it is known as a tool to detect attacks on containers and Kubernetes.\nMercari runs many of its services on Kubernetes (Google Kubernetes Engine) and has been using Falco since 2020 to detect attacks on Kubernetes clusters and record traces of the attacks. At the time of implementation in 2020, Hiroki Suezawa(@rung) performed threat modeling and compared its functionality with other tools before adopting it. It has been two years since then, more Kubernetes security threat information is available, and new rules have been added to Falco. Therefore, we conducted threat modeling again to evaluate new open source Falco rules. We then created new rules to detect attack methods that are not covered by the existing rules found during our threat modeling, and implemented and verified these new rules in the production environment.\nThreat modeling for Kubernetes clusters Threat modeling is the process of identifying security threats to a system and is often performed when designing a system. In this case, however, we focused on a Kubernetes cluster that is already in operation and how an attacker intrudes and gains a foothold to attack the Kubernetes cluster. Threat modeling for Kubernetes clusters is based on the Threat matrix for Kubernetes published by Microsoft. The Threat matrix is a list of attack methods from MITRE ATT\u0026amp;CK, a collection of cyber-attack methods, that are applicable to Kubernetes. It describes the attacker’s actions in the attack lifecycle of a Kubernetes cluster, starting with Initial Access, followed by Execution, Privilege Escalation, Credential Access, Discovery, and Lateral Movement. In the threat modeling, we have supplemented the attack techniques that were missing in Microsoft’s Threat matrix for Kubernetes by referring to MITRE ATT\u0026amp;CK’s Containers Matrix and other sources as appropriate. For example, we have added the following additional attack methods: checking privileges after an intrusion, mounting a Container socket, adding Capability, which is a potential Container Escape risk, and executing a Container Escape Exploit.\nThe Threat matrix created by threat modeling based on the above looks like this.\nThe attack techniques marked in green have been added to the Threat matrix for Kubernetes by us and are detailed below.\nExecution Debug by ephemeral container: If the attacker has access to Kubernetes, the new kubectl debug in addition to the existing kubectl exec allows arbitrary code execution in the container via an Ephemeral container. Privilege Escalation Too many capabilities: The risk of container escaping is increased by granting a specific Capability to the container, such as CAP_SYS_ADMIN. If a container is escaped, An Attacker can perform operations on the host. Weak AppArmorProfile: Disabling the AppArmor profile, which restricts behavior inside containers, increases the risk of container escapes. A container escape allows an Attacker to perform operations on the host directly. Mount container socket: Mounting a Socket with access to the container runtime allows you to manipulate other containers and the host from inside the container Sharing Host Namespace: Sharing Host Namespaces such as Host Network and Host PIDs leads to privilege escalation from inside the container. Kernel exploit to escape container: Container escape through attack code exploiting kernel vulnerability, allowing operation on the host. Credential Access Read process environment variables: If environment variables are leaked, various credentials like Cloud Secret Access Key and configuration values may be stolen making it possible to access other resources. Discovery Checking pod settings inside container: Determine what permissions are granted to the container by examining the internal file system, etc. Install discovery tool outside container: Network scanning tools and other tools installed from the outside can lead to an investigation of the Kubernetes environment for infiltration escalation. We also implemented attack code for each specific technique. We then compiled a spreadsheet containing the attack methods, the implementation, and other references so that anyone could reproduce and verify them simply by looking at the Threat matrix and the spreadsheet.\nWe aimed to cover all attack methods by conducting threat modeling and creating a threat matrix. One important thing to note is that an attacker would be using a combination of these attacks rather than just one; for example, they might attack via Initial Access, Execution, and Privilege Escalation methods to spread their attacks. Thus, in updating Falco’s attack detection rules (described in the next chapter), we aimed to create a set of rules that would allow us to detect each phase of such an attack.\nUpdating Falco’s Attack Detection Rules For our verification purposes, We executed each attack in the threat matrix on a Kubernetes cluster and checked whether Falco could detect each of them. Based on the results, we created new rules for Falco and patched the existing rules where necessary.\nAn example of a new rule we created was a detection rule for the “Read process environment variables” technique that we added to the Threat matrix. This rule detects when processes read from /proc/self/environ and /proc/1/environ files; both files are accessed when reading the environment variables via SSRF or Path traversal vulnerabilities. In many cases environment variables store important information such as credentials for accessing other resources and application configuration values. In addition to the above, Linux provides files under /proc that allows programs to obtain various interface information. Particularly, it provides files in the form of /proc/[pid]/environ that allows programs to obtain the contents of environment variables for a specific process, specified by a pid.\nFor example, let us assume that a Pod was created with an environment variable containing some credential information using the manifest below.\nkind: Pod apiVersion: v1 spec: containers: - name: ssrf-poc env: - name: MY_SECRET value: 8c2886dca39e7b692cb378e704072ad4 If the attacker is able to read the contents of /proc/self/environ (note: here “self” is used instead of a pid to specify the environment variable for the current process), the confidential information MY_SECRET set in the Pod can easily be stolen.\nKUBERNETES_PORT=tcp://10.24.0.1:443 KUBERNETES_SERVICE_PORT=443 ... MY_SECRET=8c2886dca39e7b692cb378e704072ad4 This rule should be useful in many environments, and so we have created a Pull Request to the Falco repository, which they have since merged. (Add new rule that detect retrieving environment variables from /proc files #2193 – Falcosecurity/Falco)\nIn addition, we created 8 other Pull Requests to fix bugs in the existing rules or to make them more robust. while working closely with the Falco team as we communicated.\nFalco detection evasion via symbolic links, and countermeasures We also investigated methods to evade Falco’s detection during our research on threat models and detection rules. In particular, I paid attention to the file path detection evasion method using /proc/self/root in Symbolic link files introduced in Kohei Morita(@mrtc0)’s article \u0026quot;How to Bypass Falco\u0026quot;.\nWhen you perform an operation on a file in Linux, the openat system call is executed to open that file. The second argument to the openat system call contains a file path. For example, cat /etc/shadow command will invoke the following openat system call.\nopenat(AT_FDCWD, name=/etc/shadow, flags=1(O_RDONLY)) Falco can detect these system calls and also provides users with the filename being accessed. In the above example, the filename /etc/shadow will be stored in a variable named fd.name. Falco’s detection rules may use this to analyze the action and possibly raise a flag. For example, the “Read sensitive file trusted after startup” rule uses this fd.name variable to detect access to files containing potentially sensitive data. However, one thing to note is that Falco tries to provide fd.name as an absolute path, which means that it will try to logically resolve relative path specifications such as . and ... For example, a path like /var/spool/cron/crontabs/../shadow will be resolved to /var/spool/cron/shadow which is then made available in the fd.name variable by Falco.\nAt this point we must consider the existence of symbolic links. A symbolic link is a link that points to another path. For example, in Ubuntu, /proc/self/root/ is a symbolic link to / (the root directory), therefore it is possible to specify the file /etc/shadow as /proc/self/root/etc/shadow: they will point to the exact same file. To find out the list of symbolic links on your system, you can execute the following command, and you will be presented with the list of available symbolic links.\n# find / -type l -xtype d -ls 2\u0026gt; /dev/null 1554024 0 lrwxrwxrwx 1 root root 9 Aug 15 11:50 /lib64 -\u0026gt; usr/lib64 12 0 lrwxrwxrwx 1 root root root 13 Sep 15 04:36 /dev/fd -\u0026gt; /proc/self/fd For our purposes, we are interested in symbolic links that point to certain “interesting” directories:\n/proc/self/root -\u0026gt; / /proc/self/cwd -\u0026gt; (process dir) /dev/fd -\u0026gt; /proc/self/fd /var/spool/cron/crontabs -\u0026gt; /etc/crontabs /var/spool/mail -\u0026gt; /var/mail Note that in the above example /var/spool/cron/crontabs actually points to /etc/crontabs. With this knowledge in mind, you might realize that the path /var/spool/cron/crontabs/../shadow actually points to /etc/crontabs/../shadow, which in turn resolves to /etc/shadow, as can also be seen in the following table.\nArguments of the openat system call Falco’s fd.name Actual file path to be accessed /var/spool/cron/crontabs/ /var/spool/cron/crontabs/ /etc/crontabs /var/spool/cron/crontabs/../ /var/spool/cron/ /etc/ /var/spool/cron/crontabs/../shadow /var/spool/cron/shadow /etc/shadow However, when Falco reports on the cat /var/spool/cron/crontabs/../shadow command being executed, Falco only resolves the file path of the argument of the openat system call to /var/spool/cron/shadow and passes it to fd.name, without resolving the symbolic link. When an attacker uses this method, they can evade the “Read sensitive file trusted after startup”, as fd.name must match /etc/shadow exactly.\nUsing the same method we were also able to evade our newly proposed rule to detect reads against /proc/self/environ, by utilizing the fact that /dev/fd is a symbolic link to /proc/self/fd and specifying /dev/fd/../environ/ instead.\nWe have proposed to Falco a temporary solution to this problem as follows: First, as a temporary measure, we sent a Pull Request (Add rule to detect bypass by symlink files #2202) for a new rule to detect the use of directory traversal via symbolic links for specific links pointing to sensitive directories, which are present by default in widely used Docker images. However, this rule alone does not work for newly introduced or previously unknown symbolic links are used, especially when they come from other container images or are created by packages that the users installed. To solve this problem we have created a new issue to discuss Symbolic link paths in the generation of fd.name. This is still under continuous discussion under the Issue (Discuss about fundamental solution of detecting symlink file based bypass method #2203).\nLimitations of attack detection by Falco and what to expect in the future In this section, we will introduce our perceived effectiveness and limitations of Falco during our work, including the deployment of detection rules to Mercari’s actual production environment. As mentioned at the introduction, Falco collects executed syscalls and detects them according to predefined rules. This detection technique is very effective for attacks that always execute a specific syscall. For example, attacks that require access to specific well-known files or attacks that must access descriptors to make external communications are prime candidates However, this technique falls short when trying to detect following types of attacks.\nAttacks that are completed within the application layer (i.e. no syscalls are made) Attacks that use a combination of multiple syscalls, and thus cannot be identified by a single syscall For attacks such as SQL injection that are completed within the application layer, it requires a fundamentally separate approach than syscall-based detection. For attacks using multiple syscalls, while Falco is currently only capable of detecting single syscall-based attacks, we are hoping to see improvements to Flaco’s functionality that allows it to identify these attacks in the future. We also believe that Falco will benefit greatly if they can decrease the amount of false positives. Currently Falco detection has a high rate of false positives, and If Falco can reduce these by only raising alerts when a combination of multiple high-risk behaviors are identified, it should increase Falco’s usability even more.\nFinally, we would very much like to see a way to prune multiple identical alerts. For example, when a Pod that contains a potential vulnerability is deployed at scale, we would be overwhelmed by the same alerts. At Mercari we have developed a mechanism to first intercept these alerts within a common monitoring platform, which then consolidates them before sending the alerts to responsible staff. It would be nice if a similar feature were to be implemented upstream.\nFinal words I would like to thank Hiroki Suezawa (@rung) for his mentorship, the Falco team for responding to Pull Requests and Issues, and external experts such as Chihiro Hasegawa, Kohei Morita(@mrtc0), and everyone who supported my internship.\nThis article is cross-posted from Mercari Engineering Blog.\n","summary":"","tags":null,"title":"Restructuring the Kubernetes Threat Matrix and Evaluating Attack Detection by Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/restructuring-the-kubernetes-threat-matrix/"},{"category":"blog","content":"Dear Falco community,\nThe Falco project is excited to announce that on Nov 4, 2022, the project maintainers submitted the PR to be considered for graduation. This milestone is important because it demonstrates the health and maturity of the project to the Kubernetes \u0026amp; cloud ecosystem.\nFalco joined the CNCF as a Sandbox project in the fall of 2018 and evolved into Incubating status two years later. The community believes the next natural step is for Falco to apply for graduation. The project has reached maturity in community health, diversity of contributions \u0026amp; contributors, and ecosystem adoption.\nWhy is Falco ready to graduate? Falco’s adoption has grown widespread within the Kubernetes ecosystem; users of the project include AWS, Qonto, Shopify, and many others. The project has been integrated into a variety of derivative open source and commercial products such as R6/Phoenix, Giant Swarm AppPlatform, gVisor, StackRox, Tarian, Sysdig Secure, and many more.\nSince incubation, the amount of contributions coming from organizations other than Falco's original creator (Sysdig) has grown steadily. During the last year, around 38% of the contributions came from a diverse group of committers that includes: Innoteam, Amazon, Samsung, IBM, Mercari, RedHat, and many individual contributors. More details are available here.\nFalco currently stands with 5,300+ GitHub stars and 165+ contributors across the various repos in the falcosecurity GitHub organization. The community has also expanded its footprint to 1,695 users registered in the Falco community Slack channel.\nProject highlights for 2022 Github stars: + 26% Core repo contributors: +65% Forks: +7% Slack channel members: +126% Downloads: 41.7M Docker hub pulls (25% growth) 1.2M AWS ECR New features in Falco The most significant additions since acceptance for Incubation include:\nStable release schedule Contribution of the whole libs source code into the Falcosecurity organization Plugin framework, allowing event sources other than syscalls New eBPF probe gVisor integration Community maturity The project has grown an active and engaged leadership committee and has been stable for the past year. We believe Falco has proven maturity in their maintenance processes that shows stability as a whole. We are proud to also highlight that since incubation, Falco has added maintainers from 4 new organizations.\nFalco has also demonstrated consistent application of governance and community growth processes. We strongly believe that the community has evidence of happy and healthy contributors and maintainers. We've also facilatated and clarified roles to empower maintainers and contributors to follow a path of advancing contributions.\nHow can you help today? Go here: Falco graduation proposal. If you are a fan of Falco, we would love a 👍, ❤️, or 🚀 on this PR. If you are using Falco in production, please add your name to our ADOPTERS.md document. If you do any of the above, share it on the social media platform of your choice. ","summary":"","tags":["Community"],"title":"Falco applies for graduation","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-applies-for-graduation/"},{"category":"blog","content":"It was KubeCon recently. I doubt anyone reading this didn't know about it. And if you attended, you're probably still receiving e-mails about the event.\nKubeCon is where everyone wants to be. And Falco was there too. It did indeed have a great presence: A project meeting, mentions, a few presentations, a keynote, it even had a party!\nOnce there, it was Falco time!\nProject Meeting A project meeting is where maintainers of the project, users, adopters and contributors have the opportunity to exchange impressions. On Tuesday afternoon, Falco maintainers met with interested users and potential adopters, and presented, not only the background of the project, but also its future roadmap.\nThere were questions from the attendees, requests and announcements of upcoming features, and even live demos. From the new plugins framework till the recent gVisor support, including a deep explanation of Falco libraries' insights. If you didn't know how Falco worked internally, you could leave the room being an expert.\nPresentations Falco is a well known project. It was mentioned in at least five presentations. Some of these, delivered by the core maintainers. Others, by the community or the CNCF organization itself. Its presence in so many occasions reflected the project's reputation in the community.\nKeynote Tuesday morning. Still tired from the jet-lag, and after the first day of Cloud Native SecurityCon, our first public Falco moment of the day: A Keynote at the SecurityCon delivered by Loris Degioanni, original creator of Falco.\nLoris introduced the new GitHub Plugin for Falco, which is capable of detecting events like using GitHub actions for cryptominers, pushing code with secrets, or even detecting when someone starred the repository.\nThe time dedicated to a keynote is usually short, but for Loris it seemed to be enough to perform a couple of live demos. Don't miss them in this video.\nDetecting Threats in GitHub with Falco - Loris Degioanni\nThe Eye of Falco That same day, a few hours later, Stefano Chierici, Senior Security Researcher, and Lorenzo Susini, Open Source Engineer, both contributors of Falco, presented one of the most exciting of its features: Detection of attempts to escape Linux capabilities.\nDuring this presentation, Lorenzo did an extensive walkthough on Linux capabilities, explaining the security situation before having them, detailing on its different sets (effective, permitted and inheritable) and its security implications when creating new processes that require higher privileges.\nStefano, on the other side, walked us through different scenarios showing a variety of real attacks. Therefore, having the CAP_SYS_MODULE capability enabled in the container would allow an attacker to use a Kernel Module to attack; having the CAP_SYS_PTRACE capability active would allow the injection of malicious code into memory; and having the CAP_SYS_ADMIN capability might open more than one path to make our host exploitable.\nTrying not to spoil the end of the presentation (you can already imagine it though), we recommend to watch the following video to see how Falco faces this kind of threats, as it does with many others, by obtaining the state of the container and warning the user if the capabilities exceed the desirable ones.\nThe Eye of Falco: You Can Escape but Not Hide - Stefano Chierici \u0026amp; Lorenzo Susini\nDetecting the Undetectable Falso also squeezed into a presentation from Carol Valencia, Cloud Native Security Advocate at Aqua Security, where she demonstrated how three different runtime security solutions, Falco among them, were able to detect fileless attacks.\nFileless Attack - Detecting the Undetectable\nFalco Project Updates For those that were not able to attend the Project Meetings at the SecurityCon, KubeCon was a second great opportunity to learn from their favority CNCF projects.\nOn Friday afternoon, Jason Dellaluce and Luca Guerra, both Open Source Engineers, as well as Falco maintainers, gave an overview of the Falco project and its recent updates.\nSecurity In the Cloud With Falco: Overview And Project Updates - Jason Dellaluce \u0026amp; Luca Guerra\nFalco Kiosk at the CNCF Pavillion This year at the KubeCon, Falco maintainers spent a good amount of time at the Falco kiosk. They received visitors interested in the project, some, already users of Falco, others, new users looking to learn about it, even a couple of youtubers asking to interview the maintainers for their channels.\nAll in all, an awesome chance to discover, first hand, what people really thought of Falco, wonders and pain points, good and not so good experiences with the tool and its ecosystem. In other words, real and valuable feedback.\nBook signing We haven't mentioned it yet, but Falco even had a book at the KubeCon. Shortly before the event, O'Reilly published Practical Cloud Native Security with Falco, written by Loris Degionni and Leonardo Grasso, both Falco maintainers with a large experience in the project.\nWednesday and Thursday, Loris and Leo spent some time signing copies of their book to users and developers interested in learning the secrets of Falco. Receiving a book at the KubeCon is probably not such a highligh anymore. Receiving Falco users willing to queue to receive your book is still a rewarding experience though.\nParty KubeCon is not only about collecting swag and attending presentations, although these are a great source of knowledge (and the swag a lot of stolen space in your luggage). KubeCon is also about interacting with other attendees, having exciting conversations, sharing experiences and point of views.\nSo Falco thought of using an evening to do exactly that!\nPeople at the event (let's call it a party!). So people at the party enjoyed some food, drinks, had meaningful conversations -at least, that's what we want to believe-, and played Cards against Containers -the paper version, not the online one.\nSince the party took place on Tuesday, it meant a nice break between two days full of Security-related presentations, and the KubeCon starting the next day. We didn't stay long, but we had some joy.\nConclusion As you can see, it was a week full of emotions, opportunities, friends and colleagues, and Falco. We are already looking forward to the next event, and we hope you too.\nAnd if you didn't get your copy of the book, maybe there'll be another chance next year in Seattle or Amsterdam ;-)\n","summary":"","tags":["Community","Live Event","Kubernetes"],"title":"Falco at the KubeCon NA 2022","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-kubecon-2022/"},{"category":"blog","content":"If you are reading this, your source code is likely your most important asset: not only it is at the base of the applications that power your business, but if you operate in the cloud, it’s also likely how you define and control your infrastructure. And, quite probably, your code is stored in one or more git repositories, hosted on GitHub.\nAs the home of such important assets, GitHub repositories should be at the top of your list of security priorities. However, based on my experience, many people fail to put in place even basic measures to protect source code repositories. This blog looks at three important threats to GitHub repos. You will learn what they are and how you can reliably detect them, as they happen, using the Falco open source security tool.\nThe three Biggest GitHub security risks 1. Pushing secrets into repos If there was a competition for the worst thing that can happen to your team on GitHub, pushing secrets into repos would win first prize. No matter how disciplined one is with this, secrets (passwords, tokens, API keys, etc.) always find a way into repositories.\nCase in point, I searched GitHub for “remove secret”. Among the results were 451K commits; the ones on top at the time of writing this article included examples like this one or this one. There are even research papers on how bad the phenomenon is!\nLeaking secrets is of course a big deal when the repository is public, since hackers actively scan GitHub, hunting for any type of secrets that they can immediately take advantage of. However, secrets in private repositories are a major security threat as well, as they can be exploited for privilege escalation and lateral movement.\nProtecting from secret leaks is not trivial for many reasons, such as:\nin any team of non-negligible size, it is hard to control how each single member accesses git and what she commits. Even super useful tools like AWS’s git-secrets need to be installed on every client to be effective. data cannot completely be deleted from git, so removed secrets still appear in the repository’s history. This is why, despite the problem being well known, countless high-profile data breaches happened over the years because of secret leaks, including a very recent one at Toyota.\n2. Crypto mining through GitHub Actions GitHub Actions offer the ability to run arbitrary code in response to selected GitHub events (for example, merging a PR). They are a great way to extend code repositories with automation and integrations. GitHub Actions are executed by a computing pool provided by GitHub/Microsoft. Only problem: such a computing pool is also a juicy target for the bad guys trying to make a quick buck by mining bitcoin. This recent analysis by TrendMicro offers a good overview of the techniques used by attackers to deploy miners through GitHub Actions.\nYou might think that mining is mostly a problem for GitHub. They own preventing the bad guys from creating a huge number of repositories and abusing resources. However, this can quickly become your problem. For example, when someone uses a malicious action, importing it from an external source or the GitHub Marketplace. Note how malicious actors have been shown to inject mining actions into repositories by simply opening a PR. As shown here, in some cases the PR doesn’t even need to be approved for the action to run.\nRunning an action, according to the github pricing calculator, can cost you more than $300 per day, so a breach of this type can quickly cause your bill to explode.\n3. Mistakenly publishing a private repository Ahh, that feeling when you just realized that one of your team members has published the wrong repository (maybe one that includes your secrets!) and, by the time you find out, somebody has already forked it. I actually experienced that feeling once and, let me tell you, it’s very much not something I enjoyed.\nYes, GitHub gives you a warning and requires you to type the name of the repo. And yes, despite that, this still happens.\nDetecting these three threats (and more!) using Falco The three scenarios described above have one thing in common: they need to be detected quickly, very quickly, because the damage they cause grows exponentially with time. Fortunately, Falco can help! Falco is well known for its system calls-based runtime detection capabilities, and for its rich containers and Kubernetes support. Now, with the recently released GitHub plugin, Falco turns into a great tool to protect your code repositories. Falco was designed to work in real time, so it allows you to detect threats very quickly and respond accordingly.\nHow it works Integrating Falco with GitHub is pretty straightforward, following the steps in the diagram below:\nFalco is given a GitHub token. It uses the token to set up a webhook for each of the repositories that you specify. It then listens to every message sent by GitHub on those webhooks, filters and interprets the message’s data, and sends you meaningful alerts when something bad happens, in a matter of seconds. You can route these alerts to your favorite notification channels (email, Slack, a SIEM tool), or you can leverage them in a response engine to automatically remediate the issue.\nNote Falco operates in true streaming fashion: it doesn’t copy, store or index any data. This makes it inexpensive, easy to run, and super responsive.\nUnpacking Falco’s GitHub rules Falco’s currently available GitHub rules can be found here. Here are, for example, the rules that detect the execution of an action with crypto miners:\n- rule: Github action with miners desc: a github action containing crypto miners was executed condition: \u0026gt; github.type=workflow_run and github.workflow.has_miners=true output: \u0026gt; a github action containing crypto miners was executed (repository=%github.repo repo_owner=%github.owner org=%github.org user=%github.user file=%github.workflow.filename) priority: CRITICAL source: github Note how the condition field filters for webhook messages of type workflow_run that point to the execution of miners. Github.workflow.has_miners is where the magic happens. It fetches the workflow’s definition file and scans it line by line, looking for patterns that identify the execution of one of the well known miner binaries.\nFor reference, here are the rules that detect the other two classes of threats described in this blog post:\n- rule: Secret pushed into a public repository desc: A secret (AWS keys, github token...) was committed into a public repository condition: \u0026gt; github.type=push and github.diff.has_secrets = true and github.repo.public=true output: \u0026gt; One or more secrets were pushed into a private repository (repository=%github.repo repo_owner=%github.owner org=%github.org user=%github.user secret_types=%github.diff.committed_secrets.desc file=%github.diff.committed_secrets.files line=%github.diff.committed_secrets.lines url=%github.diff.committed_secrets.links) priority: CRITICAL source: github - rule: Private Repository Becoming Public desc: Detect changing the visibility of a repository to public condition: \u0026gt; github.type=repository and github.action=publicized output: \u0026gt; A repository went from private to public (repository=%github.repo repo_owner=%github.owner org=%github.org user=%github.user) priority: CRITICAL source: github When the condition in one of the rules is met, Falco will send you a message formatted as specified by the output field, which includes a bunch of useful contexts. As you can see, these rules are very simple, which means it’s easy for you to customize them, or create new ones that fit your specific needs.\nWhere can you get started? Instructions to get you up and running can be found in Falco’s plugins repository. The same page documents the list of fields you can use to create your own rules. If it all goes well, it will only take a few minutes for your repos to be protected, and for you to sleep well again!\nAs usual, if you have any feedback or need help, you can find us at any of the following locations.\nGet started in Falco.org Check out the Falco project on GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":null,"title":"Using Falco to Protect Against the Three Biggest GitHub Security Risks","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-plugin-github/"},{"category":"blog","content":"Dear community, today we are happy to announce the release of Falco 0.33.0 🎉!\nA big thank you to the community for helping get the latest release over the finish line. The Falco community rallied behind this release and we wanted to share some of the latest novelties you’ll find in this most recent launch. To read a more detailed account of the release, check out v0.33.0 in the changelog.\nWhat’s New? 🗞️ In this release we saw more than 160 pull requests across the repos of Falco and the libraries. We had a total of 20+ individual contributors. We’d like to give a special shout-out to Andrea Terzolo and Melissa Kilby for standing out as two of the most high-impact contributors for this release.\nThe project really seems to be more alive than ever! Thank you to our maintainers and contributors, as this would not happen without your support.\nUpdates - TLDR; 🚀 In release v0.33.0 the community focused on addressing the following updates \u0026amp; changes:\nLibs now allow individual selection of which syscalls to collect during live captures, which helps Falco improve performance and reduce dropped events Introduced the Kernel Crawler, a new tool that automatically identifies the most up to date kernel versions supported by popular distros Syscall kernel ring-buffer size is now customizable for your environment needs Mitigations for libsinsp’s Kubernetes metadata client to address recent issues that caused Falco to crash Support for multiple simultaneous event sources, which means that you can now run multiple event sources in the same Falco instance Added minikube as a supported platform in the driver loader and included it in our driver build matrix Rule alert rate limiter is now optional and disabled at default Support for two new syscalls and many improvements to the default Falco security ruleset Selecting Interesting Syscalls ⚙️ A historical challenge when using Falco with a large system was to keep up with large amounts of kernel events. In the past, this was mitigated by what used to be called “simple consumer mode”, through which Falco discarded kernel events that were not useful for runtime security purposes. However, we lacked support for individually selecting which syscalls had to be collected and which to discard. This feature has been requested by the community for a while, as it is a great bonus point for both Falco and all other projects based on top of the Falco libraries. In this release, we refactored the whole system and introduced new libsinsp APIs that allow to individually select which syscalls and tracepoint events need to be instrumented for collection in the kernel. Now, Falco has higher control over collected security events, and is able to improve performance and reduce the amount of dropped events. At the same time, other projects can easily consume only the events they need without any additional instrumentation overhead.\nKernel Crawler 🔍 When deploying Falco, one of the biggest challenges has been to compile its drivers (kernel module or eBPF probe) for the specific kernel versions and customization you wish to instrument. To help our community, the Falco project has created prebuilt kernel modules and eBPF probes for widely-adopted distros and kernel versions. We have also provided a \u0026quot;driver loader\u0026quot; script that takes care of downloading and installing them before attempting local compilation. The build matrix has so far been constructed manually depending on the community demand and contributions, which makes it very hard to keep up with the most recent kernel versions.\nRecently, the Kernel Crawler joined the Falco ecosystem as a tool that automatically searches for the most up to date kernels supported by multiple Linux distros (huge thanks to Federico Di Pierro for leading the effort). This helped us to dramatically expand our driver build matrix, and keeps it up to date with the latest kernel versions supported by the most popular distros without the need of manual intervention. This is a major step forward for Falco’s adoption, which we now expect to grow even further. Moreover, the Kernel Crawler populates an open database with all the information it collects. This is both a reference of the kernel versions and the distros supported by Falco, and a useful source of information for communities working in the space of kernel instrumentation like we couldn’t find on the internet so far.\nCustomizing the Syscall Kernel Ring-Buffer Size 💍 The ring-buffer is the shared piece of memory between Falco and the drivers in which all kernel events are pushed upon collection for Falco to consume them. When Falco is not able to keep up with the high throughput of events pushed, the buffer becomes full and some events are inevitably dropped.\nThanks to the great effort driven by Andrea Terzolo and Melissa Kilby, the syscall kernel ring-buffer size is now variable and configurable. In some cases, tuning this size may lead to better performance and less event drops on certain machines and environments. If you’re interested, check out the discussion at falcosecurity/libs#584.\nMitigations for Kubernetes Metadata Client ☸️ Starting from June’s Falco release, we included minor fixes for the Kubernetes client bundled inside libsinsp. This is the piece of code responsible for downloading metadata from your API server and populating fields in your security rules such as k8s.deployment.name, k8s.rc.name, etc. However, this causes Falco to receive too much data in certain situations, and to eventually crash. You can find more details in the following issue: falcosecurity/falco#1909.\nFinding a stable and permanent solution is still being researched, as the problem of data overload has some intrinsic complexity. In this release, we introduced some short term solutions that prevent Falco from crashing in those scenarios by discarding useless information and handling errors gracefully. However, the big problem identified is that the Kubernetes cluster provides too much data, and we will keep looking for optimal solutions to this challenge in the future.\nRunning Multiple Simultaneous Event Sources 🚴 Wouldn’t it be nice if Falco could multi-task? Well, now it sorta can! We are delighted to announce that in this release Falco can now run multiple event sources in parallel. What does this mean? Well, it means that you can run plugins and syscall collections on the same Falco instance.\nHistorically, Falco supported consuming events from one source only. The only exception was the legacy support of the Kubernetes Audit Events, which allowed receiving those events and kernel events simultaneously. However, it was non-standard and has been substituted in favor of a plugin-based solution starting from Falco 0.32.0. Up until now, this meant that to consume events from more than one event source, users needed to deploy many instances of Falco, each configured with a different source.\nThis is a huge improvement and also brings back support for running syscall and k8s audit logs in the same Falco instance, for all the folks who were interested in doing so. For insights about the principles and rationale behind this release, follow the discussion at falcosecurity/falco#2074.\nPlease note that this feature introduces few user-facing changes to be aware of when updating. The primary one is that the syscall event sources will always be enabled by default if not explicitly disabled. So, please make sure you pass --disable-source=syscall to the Falco CLI if you’re interested in a plugin-only deployment! You can find more details in the documentation.\nSupporting minikube in the Driver Loader 📥 We now offer new prebuilt drivers for the three most recent major version releases of minikube, which is a newly-supported platform for the Falco driver loader.\nIn general, it’s not possible to compile the Falco drivers locally when deploying on minikube, so in the past we needed to wait for a new minikube release to bundle the most recent Falco drivers. Thanks to the new Kernel Crawler, and great work carried out by Aldo Lacuku, our driver build grid now supports and auto-discovers the driver configurations for minikube and provides users with pre-built drivers to download with the driver loader. This reduces release delays to the bare minimum, and running Falco on minikube has never been easier!\nDisabling Alert Rate Limiter at Default ❗ Falco provides a throttling mechanism for reducing the number of rule alerts, with the purpose of reducing noise in some environments. However, some users found concerns in this approach, as in the discussion at falcosecurity/falco#1333.\nFalco v0.33.0 makes the rate limiter optional, and disables it in the default configuration, so that there is never a risk of discarding important alerts. At the same time, the feature is still present and configurable for everyone who needs to reduce Falco’s noise in their environment.\nUpdates on Syscall Coverage and Security Rules 🛡️ Call and you shall receive! Okay, that’s not exactly how that saying goes, but we acknowledged the importance of instrumentation coverage and critical updates to syscalls. After all, the power of Falco’s runtime security lies in the visibility it has over the system it gets deployed into. With this new release, Falco supports the collection of two new syscalls to ensure we keep those pesky hackers away: fsconfig and mlock2.\nOn top of that, there have been major updates to the default set of security rules bundled in Falco.\nSince the last release, three new security rules have been added. Special thanks go to hi120ki for having been very active in maintaining the security rules over the past few months, and much of his work will be part of the next Falco releases as well. For v0.33.0, the new rules are:\nDirectory traversal monitored file read: detects attacks based on directory traversal Modify Container Entrypoint: detects attacks based on CVE-2019-5736 Read environment variable from /proc files: detects attempts to read process environment variables Additionally, existing rules have been updated to become less noisy and more optimized. Huge thanks to Melissa Kilby for taking the initiative to clean up the ruleset by disabling by default all the rules that were proved to never be triggered by Falco. This is a great step forward helping Falco be more performant by having fewer rules to evaluate at runtime.\nWhat's Next? 🔮 It’s time to try out the new release! Here are some pointers for getting started with Falco:\nContainer Images falco (DockerHub, AWS ECR Gallery) falco-no-driver (DockerHub, AWS ECR Gallery) falco-driver-loader (DockerHub, AWS ECR Gallery) CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package But the party is far from being over! The community is preparing lots of exciting updates for the near future. Special mention goes to the modern eBPF probe work led by Andrea Terzolo, which is under active development and should be rolled out by the next Falco release! Moreover, there has been plenty of work on falcoctl, and we can expect a new release of the tool to come soon and bring plenty of exciting novelties in the ecosystem!\nStay Tuned 🤗 Join us in our communication channels and in our weekly community calls! It’s always great to have new members in the community and we’re looking forward to having your feedback and hearing your ideas.\nYou can find all the most up to date information at https://falco.org/community/.\nSee ya! 👋\nJason and Jacque\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.33.0 a.k.a. \"the pumpkin release 🎃\"","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-33-0/"},{"category":"blog","content":"Hello, Falcoers!\nDo you want to run Falco on Apple ARM M1 CPUs? Since Falco 0.32.1, you can! It requires a Linux virtual machine (VM) since Falco doesn't run on OSX, but it is pretty straightforward.\nLet's go step by step:\nSetting up the environment Creating a VM Creating an Emulated x86_64 VM Lima Tips Installing Falco Installing the Falco driver Running Falco Falco on M1 on Kubernetes Creating a Kubernetes cluster Deploying Falco via Helm Conclusion Setting up the environment There are a few ways to create a Linux VM on OSX using Apple Silicon, using UTM, VMWare Fusion, or Parallels. In this case we are going to use Lima, an open source project based on QEMU with lots of features, including the ability to run ARM VMs on Apple Silicon (hint: Rancher Desktop is based on Lima).\nTo install Lima, it is required to install Homebrew first. If you have Homebrew already installed, you can just skip those steps.\nNOTE: It is highly recommended to read the installation options before copying and pasting random commands. :)\nOpen the macOS terminal and paste the following snippet:\n$ /bin/bash -c \u0026#34;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)\u0026#34; After Homebrew is added, install lima as:\n$ brew install lima Creating a VM Lima has different templates already available to choose from:\n$ limactl start --list-templates almalinux alpine archlinux buildkit centos-stream debian default deprecated/centos-7 docker-rootful docker experimental/9p experimental/almalinux-9 experimental/apptainer experimental/centos-stream-9 experimental/opensuse-tumbleweed experimental/oraclelinux-9 experimental/riscv64 experimental/rocky-9 faasd fedora k3s k8s nomad opensuse oraclelinux podman rocky singularity ubuntu-lts ubuntu vmnet You can see the definition of those templates here.\nFor this exercise, we are going to launch a Fedora machine named 'falco-fedora' as:\n$ limactl start --name=falco-fedora template://fedora The previous command allows you to edit the template, choose a different one, or just deploy the VM (hint: you can skip that step using the --tty=false flag).\nAfter a few seconds, you have a Fedora VM already available! Let's connect into it:\n$ limactl shell falco-fedora $ uname -a Linux lima-falco-fedora 6.5.6-300.fc39.aarch64 #1 SMP PREEMPT_DYNAMIC Fri Oct 6 19:36:57 UTC 2023 aarch64 GNU/Linux $ cat /etc/fedora-release Fedora release 39 (Thirty Nine) Before moving forward, let's update the packages to the most recent versions and reboot the VM to use the latest kernel available:\n$ sudo bash -c \u0026#34;dnf clean all \u0026amp;\u0026amp; \\ dnf update -y \u0026amp;\u0026amp; \\ reboot\u0026#34; After a few minutes, the VM is updated and rebooted. Now it is time to install Falco!\nCreating an Emulated x86_64 VM Would you like to test in an emulated x86_64 VM? Let's set up the same Fedora VM for the x86_64 architecture.\n$ limactl start --vm-type=qemu --arch=x86_64 --name=falco-fedora-x86_64 template://fedora Drop into the VM interactively:\n$ limactl shell falco-fedora-x86_64 $ uname -a Linux lima-falco-fedora-x8664 6.5.6-300.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 6 19:57:21 UTC 2023 x86_64 GNU/Linux $ cat /etc/fedora-release Fedora release 39 (Thirty Nine) NOTE : You can always install your own custom kernel and reboot the VM into that new kernel.\nLima Tips Checkout the Advanced Configuration. For example, using additional flags such as --memory 8 --cpus 8 --mount-type \u0026quot;reverse-sshfs\u0026quot; --mount-writable when starting the VM allows for easy testing of your custom rules since your cwd from your macOS host is automatically mounted. After rebooting the VM, we observed that mounts may not work anymore. However, leveraging limactl edit can fix it. If you encounter issues, you can force stop and delete the VM, and then rebuild it. For instance, you can use the following commands: limactl stop -f falco-fedora-x86_64 || true; limactl delete falco-fedora-x86_64 || true;. Installing Falco Let's connect to the VM again and install Falco following the official documentation:\n$ limactl shell falco-fedora $ sudo bash -c \u0026#34;rpm --import https://falco.org/repo/falcosecurity-packages.asc \u0026amp;\u0026amp; \\ curl -s -o /etc/yum.repos.d/falcosecurity.repo https://falco.org/repo/falcosecurity-rpm.repo \u0026amp;\u0026amp; \\ dnf install falco -y\u0026#34; This will install the Falco repository and signature and then install the Falco binaries and dependencies (including make and the kernel headers).\nInstalling the Falco Driver Falco depends on a driver that taps into the stream of system calls on a machine and passes them to user space. This driver can be either a kernel module or an eBPF probe (see the driver official documentation for more information).\nIn this exercise, we are going to go the eBPF route. But first, let's see if we have BPF JIT enabled (see here why it is recommended):\n$ grep CONFIG_BPF_JIT= /boot/config-$(uname -r) CONFIG_BPF_JIT=y $ sysctl -n net.core.bpf_jit_enable 1 Great, now let's install some packages required to build the eBPF probe:\n$ sudo dnf install -y clang llvm Finally, let's run the falco-driver-loader script to build the eBPF probe using the bpf command argument as:\n$ sudo falco-driver-loader bpf The output should look like:\n* Running falco-driver-loader for: falco version=0.32.2, driver version=2.0.0+driver * Running falco-driver-loader with: driver=bpf, compile=yes, download=yes * Mounting debugfs * Trying to download a prebuilt eBPF probe from https://download.falco.org/driver/2.0.0%2Bdriver/aarch64/falco_fedora_5.19.8-200.fc36.aarch64_1.o curl: (22) The requested URL returned error: 404 Unable to find a prebuilt falco eBPF probe * Trying to compile the eBPF probe (falco_fedora_5.19.8-200.fc36.aarch64_1.o) ... * eBPF probe located in /root/.falco/falco_fedora_5.19.8-200.fc36.aarch64_1.o * Success: eBPF probe symlinked to /root/.falco/falco-bpf.o The eBPF probe has been built and we are ready to go!\nRunning Falco The last step is to run Falco as a service as:\n$ sudo systemctl enable --now falco The journalctl logs should look like:\n$ sudo journalctl -fu falco Sep 15 11:07:41 lima-falco-fedora systemd[1]: Starting falco.service - Falco: Container Native Runtime Security... Sep 15 11:07:41 lima-falco-fedora systemd[1]: Started falco.service - Falco: Container Native Runtime Security. Sep 15 11:07:41 lima-falco-fedora falco[21290]: Falco version 0.32.2 Sep 15 11:07:41 lima-falco-fedora falco[21290]: Falco initialized with configuration file /etc/falco/falco.yaml Sep 15 11:07:41 lima-falco-fedora falco[21290]: Loading rules from file /etc/falco/falco_rules.yaml: Sep 15 11:07:41 lima-falco-fedora falco[21290]: Loading rules from file /etc/falco/falco_rules.local.yaml: Sep 15 11:07:41 lima-falco-fedora falco[21290]: Starting internal webserver, listening on port 8765 Sep 15 11:07:54 lima-falco-fedora falco[21290]: 11:07:54.233793746: Warning Sensitive file opened for reading by non-trusted program (user=root user_loginuid=-1 program=systemd-userwor command=systemd-userwor file=/etc/shadow parent=systemd-userdbd gparent=systemd ggparent=\u0026lt;NA\u0026gt; gggparent=\u0026lt;NA\u0026gt; container_id=host image=\u0026lt;NA\u0026gt;) Profit!!!\nThe last line in the output shows a Falco rule has already been triggered by running the previous systemctl command, so everything is working as it should. Yay!\nFalco on M1 on Kubernetes Running Falco on a single host is great, but what about running it in Kubernetes on your Apple hardware? Let's do it!\nCreating a Kubernetes cluster This time, we will leverage the k8s Lima template (basically, a vanilla Ubuntu 22.04 VM plus what is required to run Kubernetes via kubeadm) to have a single node Kubernetes cluster:\n$ limactl start --name=falco-k8s template://k8s --tty=false After a few minutes, our Kubernetes cluster is ready to be used. But first, let's get the Kubeconfig file needed to interact with the cluster:\n$ mkdir -p \u0026#34;${HOME}/.lima/falco-k8s/conf\u0026#34; $ export KUBECONFIG=\u0026#34;${HOME}/.lima/falco-k8s/conf/kubeconfig.yaml\u0026#34; $ limactl shell falco-k8s sudo cat /etc/kubernetes/admin.conf \u0026gt;$KUBECONFIG $ chmod 0600 ${KUBECONFIG} Then, we are ready to go:\n$ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-flannel kube-flannel-ds-rjk74 1/1 Running 0 17s kube-system coredns-565d847f94-5277n 0/1 Running 0 17s kube-system coredns-565d847f94-spkgc 1/1 Running 0 17s kube-system etcd-lima-falco-k8s 1/1 Running 0 31s kube-system kube-apiserver-lima-falco-k8s 1/1 Running 0 31s kube-system kube-controller-manager-lima-falco-k8s 1/1 Running 0 32s kube-system kube-proxy-265h6 1/1 Running 0 17s kube-system kube-scheduler-lima-falco-k8s 1/1 Running 0 33s Deploying Falco via Helm We leverage Helm to deploy Falco on our Kubernetes cluster using the official Falco helm chart.\nTo install Helm, we can use brew as:\n$ brew install helm Then, we need to add the falcosecurity helm repository and install the falcosecurity/falco chart.\nFor this basic example we are just going to enable eBPF as we did before, but there are tons of parameters and configurations that can be tweaked. Check the official documentation to know more.\n$ helm repo add falcosecurity https://falcosecurity.github.io/charts $ helm repo update $ helm install falco falcosecurity/falco --namespace falco --create-namespace --set driver.kind=modern-bpf This will trigger the deployment of Falco on your Kubernetes cluster. The falco-driver-loader init container will perform all the steps required to build the eBPF probe (hint: the kernel headers are already included in the VM) as you can see with the following snippet:\n$ kubectl logs -n falco $(kubectl get po -n falco -l app.kubernetes.io/name=falco -o name) -c falco-driver-loader * Setting up /usr/src links from host * Running falco-driver-loader for: falco version=0.32.2, driver version=2.0.0+driver * Running falco-driver-loader with: driver=bpf, compile=yes, download=yes ... * eBPF probe located in /root/.falco/falco_ubuntu-generic_5.15.0-47-generic_51.o * Success: eBPF probe symlinked to /root/.falco/falco-bpf.o And then, the falco pod should be running:\n$ kubectl logs -n falco $(kubectl get po -n falco -l app.kubernetes.io/name=falco -o name) -c falco Thu Sep 15 13:03:03 2022: Falco version 0.32.2 Thu Sep 15 13:03:03 2022: Falco initialized with configuration file /etc/falco/falco.yaml Thu Sep 15 13:03:03 2022: Loading rules from file /etc/falco/falco_rules.yaml: Thu Sep 15 13:03:04 2022: Loading rules from file /etc/falco/falco_rules.local.yaml: Thu Sep 15 13:03:04 2022: Starting internal webserver, listening on port 8765 Yay!\nConclusion You have learned how to set up a Linux VM to run Falco with the help of Lima in your ARM-powered Apple hardware.\nYou can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or just a friendly chat!\nIf you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Tutorial"],"title":"Running Falco on Apple Silicon","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-apple-silicon/"},{"category":"blog","content":"This post has been updated in December 2022 after initial publication. It now contains up-to-date instructions about how to use gVisor support on Docker and Kubernetes with GKE as well! The recommended version for gVisor support is now Falco 0.33.1 or above.\nFalco can now work with gVisor! So, what is it and how can we use it?\ngVisor, quoting the official documentation, is an application kernel that provides an additional layer of isolation between running applications and the host operating system. It delivers an additional security boundary for containers by intercepting and monitoring workload runtime instructions in user space before they can reach the underlying host.\nFalco, on the other hand, works by monitoring runtime system calls, normally in kernel space via a kernel module or an eBPF probe, that are then evaluated against the flexible and powerful Falco rule engine and so used to trigger security alerts.\nBefore, Falco could not work with gVisor monitored sandboxes because it is not possible to install a kernel module or eBPF probe in such an environment. But wouldn't it be great to leverage the stream of system call information that gVisor collects through its powerful monitoring system directly in Falco? This is exactly what is possible now!\nIn this article, you will learn:\n✨ The magic that allows Falco and gVisor to work together 🚀 How to run Falco with gVisor on your host with Docker ☸️ How to run Falco with gVisor on your k8s GKE cluster How Falco and gVisor work together When running containers with gVisor, there are several components that interact with our workload:\nThe Sentry is the gVisor component that implements all the application kernel functionalities. In particular, from the Falco perspective, the Sentry abstracts the system call layer and manages almost every syscall an application can ever execute. In other words, the Sentry could be seen as an alternative to our drivers: it is in the right position to put together the information contained in the events that our eBPF probe or kernel module usually generates. So, how do we turn the Sentry into a new driver for Falco?\nThe key observation here is that there is one Sentry process for each gVisor sandbox. If we want them to be able to communicate with Falco, we must set up a form of inter-process communication.\nWe decided to use a UDS (Unix Domain Socket) to handle the communication between each Sentry and Falco. Falco is acting as a server, and it is responsible for setting up the socket and listening to connections. On the other hand, each Sentry process acts as a client, and it is configured to connect to the endpoint where Falco is listening.\nWhenever a syscall gets executed inside the sandboxed application, the Sentry will manage it as usual, plus it will send a message to Falco through the UDS. Messages are serialized through Protocol Buffers so that gVisor and Falco can communicate even if they are written in different programming languages.\nOnce a message related to a syscall is received, Falco unpacks it and creates the corresponding event in a way that is consumable by our libraries. This way, it is possible to update necessary state information and trigger Falco rules whenever a match occurs!\nSetup gVisor Docker sandbox monitoring with Falco First, install Falco 0.33.1 or above and install the gVisor runsc tool 20221122.0 or above.\nYou can check the version by running:\nfalco --version ... which needs to report 0.33.1 or above and:\nrunsc --version ... which needs to report release-20221122.0 or above.\ngVisor needs to be configured to send events to Falco. Generate the appropriate configuration file:\n$ falco --gvisor-generate-config \u0026gt; /tmp/runsc_falco_config.json $ sudo mv /tmp/runsc_falco_config.json /etc/docker/runsc_falco_config.json # Don\u0026#39;t forget to protect this configuration $ sudo chmod 640 /etc/docker/runsc_falco_config.json The easiest way to run a gVisor sandbox is by using Docker. For this reason, you need to first configure Docker to work with gVisor via runsc install, and then we're going to update the runsc pod init config configuration for our Docker containers:\n$ sudo -e /etc/docker/daemon.json Then, add the runtimeArgs key with the --pod-init-config= parameter like in the example below:\n{ \u0026#34;runtimes\u0026#34;: { \u0026#34;runsc\u0026#34;: { \u0026#34;path\u0026#34;: \u0026#34;/usr/local/bin/runsc\u0026#34;, --- Do not forget the comma at the end of the previous line. --- --- Add the following config, not these instructions. --- \u0026#34;runtimeArgs\u0026#34;: [ \u0026#34;--pod-init-config=/etc/docker/runsc_falco_config.json\u0026#34; --- End of added config. --- --- Have I told you not to include these instructions. --- ] } } } Then, restart the Docker daemon to let it use the new configuration:\n$ sudo systemctl restart docker Runtime detection in action Now it's time to put everything together and see how to use Falco to monitor gVisor sandboxes! To start monitoring gVisor sandboxes, you can use the -g or --gvisor-config options, passing the path to the pod init config. Falco uses that config file for two main reasons:\nExtract the path of the UDS that needs to be created Create a trace session for all the already existing gVisor sandboxes. New ones will directly connect to the running Falco instance as we configured in the previous step. Run Falco stand-alone Simply run Falco on the command line:\n$ sudo falco --gvisor-config=/etc/docker/runsc_falco_config.json You're now monitoring your gVisor sandboxes!\nExample permanent configuration with Systemd Alternatively, for a more permanent configuration:\n$ sudo mkdir /etc/systemd/system/falco.service.d $ cat \u0026lt;\u0026lt; EOF | sudo tee /etc/systemd/system/falco.service.d/gvisor.conf [Service] ExecStartPre= ExecStopPost= ExecStart= ExecStart=/usr/bin/falco --gvisor-config=/etc/docker/runsc_falco_config.json PrivateTmp=false EOF $ sudo systemctl daemon-reload $ sudo systemctl restart falco The parameter PrivateTmp, set to false, inside the unit config file is needed since /etc/docker/runsc_falco_config.json points to /tmp/gvisor.sock.\nChanging the /tmp/gvisor.sock file to /run/gvisor.sock would avoid that we have to use that parameter, and the temporary directory would remain private.\nFalco will load the configuration indicating it with a line similar to:\nThu Jul 21 15:41:58 2022: Enabled event collection from gVisor. Configuration path: /etc/docker/runsc_falco_config.json Now we can run any container with gVisor:\n$ sudo docker run --runtime=runsc -it ubuntu bash If all goes well, the container will start properly configured to be monitored by Falco! To test the detection capabilities, try to trigger a simple rule like Write below binary dir:\n$ touch /bin/foo You will see Falco alerting:\n07:47:42.173335167: Error File below a known binary directory opened for writing (user=root user_loginuid=0 command=touch touch /bin/foo file=/bin/foo parent=bash pcmdline=bash bash gparent=\u0026lt;NA\u0026gt; container_id=f6d77af4ee3d image=ubuntu) container=f6d77af4ee3d pid=8 tid=8 Falco and gVisor in action If you don't happen to have the time to try it right now, here is a short video showing every step to follow.\nAnd if you liked this step-by-step tutorial, don't miss the one that Google has published on the gVisor blog: Configuring Falco with gVisor.\nFalco and gVisor on Kubernetes with GKE gVisor can be used to sandbox pods on GKE for higher security. If your cluster has node pools with gVisor support enabled and k8s version at least 1.24.4-gke.1800 or 1.25.0-gke.200, you can deploy an instance of Falco to monitor them via the Helm chart.\nhelm install falco-gvisor falcosecurity/falco -f https://raw.githubusercontent.com/falcosecurity/charts/master/falco/values-gvisor-gke.yaml --namespace falco-gvisor --create-namespace As simple as that! Note that this new instance is completely independent of other Falco instances that you might have that monitor your regular nodes (w/o gVisor sandboxing), so you can decide whether you want to monitor regular node pools, gVisor-enabled node pools or both!\nFor more information about these use cases and more check out the related sections of the Falco Helm chart documentation.\nLimitations and syscall support Falco supports many system call events. For its first release, gVisor does not support all of them. Our focus was to make sure the most important events used in the default rulesets are covered and enough information flows about processes, file descriptors, and connections to maintain consistency of the data throughout the analysis and rule processing. To support an event, the gVisor Sentry needs to emit it and Falco needs to be able to parse and ingest it.\nFalco and gVisor Webinar Looking for more amazing content about this integration? Then don't forget to register for this CNCF on-demand webinar where you'll learn directly from the experts! ","summary":"","tags":null,"title":"Getting started with gVisor support in Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/intro-gvisor-falco/"},{"category":"blog","content":"We use different technologies on a daily basis. Tools like Vagrant, Terraform, Ansible, and many more allow us to create and destroy digital resources in a matter of minutes, if not seconds. However, if you keep changing your running environment, you might also need to calibrate your workloads to these new changes. This is especially true when you deploy applications tightly dependent on the operating system.\nIn other words, every time you deploy an application like Falco there's a chance that you need to compile a new module or eBPF probe to get along with the current underlying kernel. This is the first of a series of posts where you will learn some interesting techniques related to how Falco generates the much needed driver and how you can make it available for your deployments.\nFalco on Docker There are many ways to run Falco: as a service, as a local container, as a Pod in Kubernetes, etc. Either way, if what we want to do is use Falco to detect threats based on syscalls, we will need a driver that has been compiled for the specific kernel running on the machine, be it a physical machine, a virtual one, or a Kubernetes node in the cloud.\nLaunching Falco as a container The Falco image embeds a script, /usr/bin/falco-driver-loader, that will automatically try to find and download a kernel module or an eBPF probe. If that wasn't possible, it might try to compile it inside the container itself. We will learn a bit more about this process and how to control it.\nHere is the output of a fresh instance of falco running on our local docker service:\n$ docker run -it --privileged \\ --name falco-driver-test \\ -v /dev:/host/dev \\ -v /etc:/host/etc:ro \\ -v /proc:/host/proc:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ docker.io/falcosecurity/falco:0.32.2 Unable to find image \u0026#39;falcosecurity/falco:0.32.2\u0026#39; locally 0.32.2: Pulling from falcosecurity/falco 7e6a53d1988f: Pull complete ... output omitted f3102eb3e85f: Pull complete Digest: sha256:5ceb23e5baae9c86fc0b160fed397facd2074ca398b770878adbb9c6d049d8a8 Status: Downloaded newer image for falcosecurity/falco:0.32.2 * Setting up /usr/src links from host * Running falco-driver-loader for: falco version=0.32.2, driver version=2.0.0+driver * Running falco-driver-loader with: driver=module, compile=yes, download=yes ================ Cleaning phase ================ * 1. Check if kernel module \u0026#39;falco\u0026#39; is still loaded: - OK! There is no \u0026#39;falco\u0026#39; module loaded. * 2. Check all versions of kernel module \u0026#39;falco\u0026#39; in dkms: - There are some versions of \u0026#39;falco\u0026#39; module in dkms. * 3. Removing all the following versions from dkms: 2.0.0+driver - Removing 2.0.0+driver... ------------------------------ Deleting module version: 2.0.0+driver completely from the DKMS tree. ------------------------------ Done. - OK! Removing \u0026#39;2.0.0+driver\u0026#39; succeeded. [SUCCESS] Cleaning phase correctly terminated. ================ Cleaning phase ================ * Looking for a falco module locally (kernel 5.10.0-14-cloud-amd64) * Trying to download a prebuilt falco module from https://download.falco.org/driver/2.0.0%2Bdriver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.ko curl: (22) The requested URL returned error: 404 Unable to find a prebuilt falco module * Trying to dkms install falco module with GCC /usr/bin/gcc DIRECTIVE: MAKE=\u0026#34;\u0026#39;/tmp/falco-dkms-make\u0026#39;\u0026#34; Creating symlink /var/lib/dkms/falco/2.0.0+driver/source -\u0026gt; /usr/src/falco-2.0.0+driver DKMS: add completed. * Running dkms build failed, couldn\u0026#39;t find /var/lib/dkms/falco/2.0.0+driver/build/make.log (with GCC /usr/bin/gcc) * Trying to dkms install falco module with GCC /usr/bin/gcc-8 DIRECTIVE: MAKE=\u0026#34;\u0026#39;/tmp/falco-dkms-make\u0026#39;\u0026#34; * Running dkms build failed, couldn\u0026#39;t find /var/lib/dkms/falco/2.0.0+driver/build/make.log (with GCC /usr/bin/gcc-8) * Trying to dkms install falco module with GCC /usr/bin/gcc-6 DIRECTIVE: MAKE=\u0026#34;\u0026#39;/tmp/falco-dkms-make\u0026#39;\u0026#34; * Running dkms build failed, couldn\u0026#39;t find /var/lib/dkms/falco/2.0.0+driver/build/make.log (with GCC /usr/bin/gcc-6) * Trying to dkms install falco module with GCC /usr/bin/gcc-5 DIRECTIVE: MAKE=\u0026#34;\u0026#39;/tmp/falco-dkms-make\u0026#39;\u0026#34; * Running dkms build failed, couldn\u0026#39;t find /var/lib/dkms/falco/2.0.0+driver/build/make.log (with GCC /usr/bin/gcc-5) * Trying to load a system falco module, if present Consider compiling your own falco driver and loading it or getting in touch with the Falco community 2022-08-31T12:00:02+0000: Falco version 0.32.2 2022-08-31T12:00:02+0000: Falco initialized with configuration file /etc/falco/falco.yaml 2022-08-31T12:00:02+0000: Loading rules from file /etc/falco/falco_rules.yaml: 2022-08-31T12:00:02+0000: Loading rules from file /etc/falco/falco_rules.local.yaml: 2022-08-31T12:00:02+0000: Starting internal webserver, listening on port 8765 2022-08-31T12:00:02+0000: Unable to load the driver. 2022-08-31T12:00:02+0000: Runtime error: error opening device /host/dev/falco0. Make sure you have root credentials and that the falco module is loaded.. Exiting. There are some important reads from this output:\nThe driver version this image tries to load is the 2.0.0+driver. This information will be really useful when we need to compile and share the driver with the falco container. By default, the container will look for a kernel module. It is possible to switch to an eBPF probe by using an environment variable, as you'll see later in this post. The falco-driver-loader script always removes the driver from memory and tries to load a current one. This is done for security reasons and the way to avoid that is not running this script when creating the container. More on this later, too. After looking in the system for a previously installed driver, the script tries to download it from the URL https://download.falco.org. Unfortunately, it doesn't seem to be able to find it and falls back to the local compilation method. When the script tries to compile the driver inside the container, it doesn't succeed because we haven't fulfilled one important prerequisite: installing the kernel headers on the host machine. In this post, we won't address that method but you can always refer to the documentation. Using Falco Driverkit As mentioned, there are different ways to obtain a valid kernel: downloading it from https://download.falco.org, compiling it via the falco-driver-loader script, or the method we'll explain here: using driverkit.\nWe don't intend this post to be an exhaustive guide to driverkit. That's also why we've chosen a relatively easy and tested target operating system: Debian.\nFirst of all, we need the driverkit tool which we'll compile ourselves. We can download the source code from https://github.com/falcosecurity/driverkit.\nWhen compiling a tool, we like using a temporary container. In this case, we'll start our container using the docker.io/golang:1.19 image and a sleep process until we're done. The ./driverkit directory will help us to extract the binary to the host filesystem. Feel free to use any other method you prefer, like docker cp.\n# This directory will contain the driverkit binary # once it is compiled inside the container $ mkdir ./driverkit # Container with Go tools $ docker run --rm -d --name golang-compiler \\ -v $PWD/driverkit:/export \\ golang:1.19 sleep infinity Check that the container has been successfully created and still runs:\n$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1ff943cbf7f9 golang:1.19 \u0026#34;sleep infinity\u0026#34; 4 seconds ago Up 3 seconds golang-compiler Next, create a shell with a terminal in the container:\n$ docker exec -it golang-compiler /bin/bash Remember, you are in the container context now. Whatever you do here will be lost unless you copy it to the /export directory. We will clone the driverkit code and compile it using the following commands:\ngit clone https://github.com/falcosecurity/driverkit cd driverkit \u0026amp;\u0026amp; make cp _output/bin/driverkit /export/driverkit exit Once we are done with the Golang container, we can stop it and it'll be automatically removed thanks to the --rm parameter that we used to start it.\ndocker stop golang-compiler -t0 Creating a configuration file for the driver request Time to create a configuration file. Do you remember the driver version: 2.0.0+driver? We will use that and additional information to create the configuration file.\n# We\u0026#39;ve included some VARIABLES that will help you understand # where the different values come from and what they represent export DRIVER_VERSION=2.0.0+driver export DRIVER_TARGET=debian export DRIVER_ARCH=$(arch) export KERNEL_VERSION=$(uname -v| cut -f1 -d\u0026#39; \u0026#39; | tr -d \\#) export KERNEL_RELEASE=$(uname -r) export DRIVER_NAME=falco export PROBE_FILE=${DRIVER_NAME}_${DRIVER_TARGET}_${KERNEL_RELEASE}_${KERNEL_VERSION}.o export MODULE_FILE=${DRIVER_NAME}_${DRIVER_TARGET}_${KERNEL_RELEASE}_${KERNEL_VERSION}.ko mkdir -p drivers/${DRIVER_VERSION}/${DRIVER_ARCH}/ # Creating the actual file that we will pass to driverkit cat \u0026gt; debian.yaml \u0026lt;\u0026lt; EOF target: ${DRIVER_TARGET} driverversion: ${DRIVER_VERSION} kernelrelease: ${KERNEL_RELEASE} kernelversion: ${KERNEL_VERSION} output: module: ./drivers/${DRIVER_VERSION}/x86_64/${MODULE_FILE} probe: ./drivers/${DRIVER_VERSION}/x86_64/${PROBE_FILE} EOF The resulting file should look like this:\n$ cat debian.yaml target: debian driverversion: 2.0.0+driver kernelrelease: 5.10.0-14-cloud-amd64 kernelversion: 1 output: module: ./drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.ko probe: ./drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.o In case you want to use a version previous to Falco 0.32.2 you might need to remove the x86_64/ string from the probe path. This is due to the expected path inside the falco-driver-loader script. These paths will be offered via an HTTP server at a later stage, so make sure they match in both steps.\nThis same file is the one we will pass to driverkit. If the driver is compiled satisfactorily, we should see a similar output in some seconds. Be patient.\n$ ./driverkit/driverkit docker -c debian.yaml INFO using config file file=debian.yaml INFO driver building, it will take a few seconds processor=docker INFO kernel module available path=./drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.ko INFO eBPF probe available path=./drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.o Make sure you use either the .yml or .yaml suffix. Otherwise, you'll get an error like:\n$ ./driverkit/driverkit docker -c debian.unknown-ext Error: exiting for validation errors Usage: driverkit docker [flags] Flags: ... output omitted FATA error executing driverkit error=\u0026#34;exiting for validation errors\u0026#34; Alternatively, we could have used a bunch of parameters in the command line, like:\n# Don\u0026#39;t forget to \\, to let the command continue after each line $ ./driverkit/driverkit docker \\ --architecture amd64 \\ --target ${DRIVER_TARGET} \\ --driverversion ${DRIVER_VERSION} \\ --kernelversion ${KERNEL_VERSION} \\ --kernelrelease ${KERNEL_RELEASE} \\ --output-probe ./drivers/${DRIVER_VERSION}/x86_64/${PROBE_FILE} \\ --output-module ./drivers/${DRIVER_VERSION}/x86_64/${MODULE_FILE} INFO driver building, it will take a few seconds processor=docker INFO kernel module available path=./drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.ko INFO eBPF probe available path=./drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.o Either way, if driverkit manages to compile the drivers, you can continue with the next step. Otherwise, you might need to adjust some of the parameters in the configuration or even customize your builder image, but we will explain that in a different post where we will deep dive into driverkit.\nLaunching Falco with the new driver There are different ways to load the driver when running Falco. We'll show you two of them: loading them manually and leaving this action to the script embedded in the container image.\nLoading the driver manually A kernel module only needs to be loaded once. So, if we load it manually before starting the container, Falco doesn't need to do it again.\nThere are two ways of achieving that, and both require avoiding the execution of the falco-driver-loader script:\nSetting the SKIP_DRIVER_LOADER environment variable to any value when creating the container. By doing so, the container entrypoint will skip the existing falco-driver-loader script. Using the image docker.io/falco/falco-no-driver, which doesn't contain that script. First, try to load the driver on the host. Look for the .ko file in the directory structure we created and load it using insmod, for instance. If the compilation was successful and the kernel version chosen was the right one, you shouldn't see any message once the module is loaded. Don't forget to do it with the user root (i.e., via sudo).\n$ find $HOME/drivers -type f drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.o drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.ko $ sudo insmod drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.ko $ lsmod | grep -i falco falco 741376 0 This first method of starting the falco container will use the docker.io/falco/falco:0.32.2 image, passing the SKIP_DRIVER_LOADER variable. We've set it to one but the script doesn't check its value.\nObserve that we're removing any existing container with that name before starting ours, but the container image remains.\n$ docker rm -f falco-driver-test # Ignore any failure here falco-driver-test $ docker run -it --privileged \\ --name falco-driver-test \\ -e SKIP_DRIVER_LOADER=1 \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ docker.io/falcosecurity/falco:0.32.2 2022-08-31T12:07:30+0000: Falco version 0.32.2 2022-08-31T12:07:30+0000: Falco initialized with configuration file /etc/falco/falco.yaml 2022-08-31T12:07:30+0000: Loading rules from file /etc/falco/falco_rules.yaml: 2022-08-31T12:07:30+0000: Loading rules from file /etc/falco/falco_rules.local.yaml: 2022-08-31T12:07:30+0000: Starting internal webserver, listening on port 8765 The second method uses the docker.io/falco/falco-no-driver image, so, as you can expect, it won't try to reload the driver this time.\nThis time, Docker will pull the image since we hadn't used it yet.\n$ docker rm -f falco-driver-test # Ignore any failure here falco-driver-test $ docker run -i -t --privileged \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ --name falco-driver-test \\ docker.io/falcosecurity/falco-no-driver:0.32.2 Unable to find image \u0026#39;falcosecurity/falco-no-driver:0.32.2\u0026#39; locally 0.32.2: Pulling from falcosecurity/falco-no-driver 1efc276f4ff9: Pull complete e34e1870ff2c: Pull complete Digest: sha256:14e6d3da56fe607ff9b0bfe91ec812ab4f4b030cea3ed88a2d31ac9b31f97fb4 Status: Downloaded newer image for falcosecurity/falco-no-driver:0.32.2 2022-08-31T12:12:40+0000: Falco version 0.32.2 2022-08-31T12:12:40+0000: Falco initialized with configuration file /etc/falco/falco.yaml 2022-08-31T12:12:40+0000: Loading rules from file /etc/falco/falco_rules.yaml: 2022-08-31T12:12:40+0000: Loading rules from file /etc/falco/falco_rules.local.yaml: 2022-08-31T12:12:40+0000: Starting internal webserver, listening on port 8765 Sharing the probe and driver with the Falco container This method is a bit more complicated than the previous one but will also give us the flexibility of deploying falco at scale.\nThe idea is simple though. After starting your favorite webserver and publishing the ./drivers directory that we created before, we'll tell the falco container to use it as a repository and download the driver from there.\nTo keep things clean, we've used the docker.io/python:latest container image, which includes the Python module http.server. If you have Python already installed on your system, you can use it directly. Just remember to define a port accessible to the falco container and pass the right IP address.\n$ docker run -d \\ --name falco-drivers-web \\ -v $PWD/drivers:/data:ro \\ docker.io/python:latest \\ bash -c \u0026#34;cd /data \u0026amp;\u0026amp; python -m http.server\u0026#34; Unable to find image \u0026#39;python:latest\u0026#39; locally latest: Pulling from library/python 1671565cc8df: Pull complete ... output omitted 4334b2fe8293: Pull complete Digest: sha256:745efdfb7e4aac9a8422bd8c62d8bc35a693e8979a240d29677cb03e6aa91052 Status: Downloaded newer image for python:latest f94cb601f85c312d62aab3e116619558239bada9f5d05e971fe26c0206828b6b Our python web server is now available and offers the drivers to any local container that might need them. Retrieve the IP address of this container for later use:\n$ docker inspect falco-drivers-web --format \u0026#39;{{ .NetworkSettings.IPAddress }}\u0026#39; 172.17.0.2 # Assign it to a variable for later use $ export DRIVERS_REPO=$(docker inspect falco-drivers-web \\ --format \u0026#39;{{ .NetworkSettings.IPAddress }}\u0026#39;):8000 $ echo $DRIVERS_REPO 172.17.0.2:8000 It's always a good practice to test that the drivers are in the right place and accessible through the webserver.\n# This is the checksum of the local files $ find ./drivers -type f -name \u0026#34;*o\u0026#34; -exec cksum {} \\; 3873827283 843080 ./drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64.ko 914371530 4980536 ./drivers/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64.o # This is the checksum of the files retrieved through HTTP $ find ./drivers -type f -name \u0026#34;*o\u0026#34; | while read FILE do URL=$(echo ${FILE} | sed -e \u0026#39;s,./drivers,\u0026#39;${DRIVERS_REPO}\u0026#39;,\u0026#39;) echo \u0026#34;$(curl -s http://${URL} | cksum) http://${URL}\u0026#34; done 3873827283 843080 localhost:8000/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64.ko 914371530 4980536 localhost:8000/2.0.0+driver/x86_64/falco_debian_5.10.0-14-cloud-amd64.o As you can see, they are accessible and identical.\nThese values will be different depending on the version of the kernel and the Falco drivers.\nLoading the kernel module Let's start with the kernel module. In this case, the only variable we need to pass is the DRIVERS_REPO one, which has been carefully prepared in the previous step.\n$ docker rm -f falco-driver-test falco-driver-test $ docker run -it --privileged \\ --name falco-driver-test \\ -v /dev:/host/dev \\ -v /etc:/host/etc:ro \\ -v /proc:/host/proc:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -e DRIVERS_REPO=${DRIVERS_REPO} \\ docker.io/falcosecurity/falco:0.32.2 * Setting up /usr/src links from host * Running falco-driver-loader for: falco version=0.32.2, driver version=2.0.0+driver * Running falco-driver-loader with: driver=module, compile=yes, download=yes ================ Cleaning phase ================ * 1. Check if kernel module \u0026#39;falco\u0026#39; is still loaded: - OK! There is no \u0026#39;falco\u0026#39; module loaded. * 2. Check all versions of kernel module \u0026#39;falco\u0026#39; in dkms: - There are some versions of \u0026#39;falco\u0026#39; module in dkms. * 3. Removing all the following versions from dkms: 2.0.0+driver - Removing 2.0.0+driver... ------------------------------ Deleting module version: 2.0.0+driver completely from the DKMS tree. ------------------------------ Done. - OK! Removing \u0026#39;2.0.0+driver\u0026#39; succeeded. [SUCCESS] Cleaning phase correctly terminated. ================ Cleaning phase ================ * Looking for a falco module locally (kernel 5.10.0-14-cloud-amd64) * Trying to download a prebuilt falco module from 172.17.0.2:8000/2.0.0%2Bdriver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.ko * Download succeeded * Success: falco module found and inserted 2022-08-31T12:36:29+0000: Falco version 0.32.2 2022-08-31T12:36:29+0000: Falco initialized with configuration file /etc/falco/falco.yaml 2022-08-31T12:36:29+0000: Loading rules from file /etc/falco/falco_rules.yaml: 2022-08-31T12:36:29+0000: Loading rules from file /etc/falco/falco_rules.local.yaml: 2022-08-31T12:36:29+0000: Starting internal webserver, listening on port 8765 It's a similar output as before, but this time we can see:\n* Trying to download a prebuilt falco module from 172.17.0.2:8000/2.0.0%2Bdriver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.ko * Download succeeded * Success: falco module found and inserted The module has been successfully loaded and Falco can start properly.\nLoading the eBPF Probe For this, we will make use of another variable, FALCO_BPF_PROBE. Like it happened with the SKIP_DRIVER_LOADER variable, its value is not as relevant as the fact that the variable had been defined. We also need to keep the DRIVERS_REPO variable, since the falco-driver-loader script will look for the probe in that URL.\n$ docker rm -f falco-driver-test falco-driver-test $ docker run -it --privileged \\ --name falco-driver-test \\ -v /dev:/host/dev \\ -v /etc:/host/etc:ro \\ -v /proc:/host/proc:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -e DRIVERS_REPO=${DRIVERS_REPO} \\ -e FALCO_BPF_PROBE=\u0026#34;\u0026#34; \\ docker.io/falcosecurity/falco:0.32.2 * Setting up /usr/src links from host * Running falco-driver-loader for: falco version=0.32.2, driver version=2.0.0+driver * Running falco-driver-loader with: driver=bpf, compile=yes, download=yes * Mounting debugfs * Trying to download a prebuilt eBPF probe from 172.17.0.2:8000/2.0.0%2Bdriver/x86_64/falco_debian_5.10.0-14-cloud-amd64_1.o * Skipping compilation, eBPF probe is already present in /root/.falco/falco_debian_5.10.0-14-cloud-amd64_1.o * eBPF probe located in /root/.falco/falco_debian_5.10.0-14-cloud-amd64_1.o * Success: eBPF probe symlinked to /root/.falco/falco-bpf.o 2022-08-31T12:58:10+0000: Falco version 0.32.2 2022-08-31T12:58:10+0000: Falco initialized with configuration file /etc/falco/falco.yaml 2022-08-31T12:58:10+0000: Loading rules from file /etc/falco/falco_rules.yaml: 2022-08-31T12:58:10+0000: Loading rules from file /etc/falco/falco_rules.local.yaml: 2022-08-31T12:58:10+0000: Starting internal webserver, listening on port 8765 This time the output is easier to read: The driver is set to bpf, the URL of the HTTP container points to our local webserver, and it also shows where it downloads the probe before starting Falco.\nDebugging As a final tip, if you want to start a container based on the regular falco image to test the falco-driver-loader script, we recommend starting the container with the --entrypoint /bin/bash parameter. This will keep the /docker-entrypoint.sh script from being executed (that one triggers /usr/bin/falco-driver-loader) and you'll have a much more comfortable environment to work with.\n$ docker run -it --privileged \\ --name falco-driver-test \\ -v /dev:/host/dev \\ -v /etc:/host/etc:ro \\ -v /proc:/host/proc:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -e DRIVERS_REPO=${DRIVERS_REPO} \\ --entrypoint /bin/bash \\ docker.io/falcosecurity/falco:0.32.2 root@e0c391e0cee1:/# Conclusion Falco requires tapping into the kernel to be able to retrieve useful information from it. For that, it has two methods: loading a kernel module in the traditional way, or using an eBPF probe. Both of them instrumentalize the kernel and provide the functionality to retrieve the relevant data.\nDue to the infinite number of combinations of Linux kernels and distributions, it is extremely difficult to offer all possible kernels as downloadable assets. Besides, in some environments, it'll be a requirement to compile the driver of such a critical component. Learning how to use Falco Driverkit will help you to easily deploy Falco in more environments.\n","summary":"","tags":["Kmod","eBPF"],"title":"Falco Driverkit with Docker on Debian","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-driverkit-debian-docker/"},{"category":"blog","content":"As a CNCF project, Falco is committed to promoting a healthy community of contributors and maintainers from multiple vendors. In aid of this, we are delighted to announce that we have updated the Falco governance documentation to help our maintainers better serve our community.\nOur goal has been to streamline and clarify roles and processes to make it easier for maintainers to do their job and for others to join the community. We fine-tuned and documented in detail the consensus-driven process we use for decision making. Additionally we clarified roles and responsibilities for contributors, and made explicit our community principles of openness, respect, transparency, diversity and vibrancy.\nThe voting PR for these updates commenced on August 22, 2022, after several weeks of discussion. The vote closed after just 4 days with 9 votes cast in favor of the changes, well exceeding the 66% majority required.\nAll Falco community members are encouraged to review the new governance and maintainers guidelines. Highlights of the revised documents include:\nFalco community principles: we continue to strive for openness, respect, transparency, diversity, and a vibrant project Leadership roles \u0026amp; responsibility: maintainers of the core repositories serve as the oversight and direction-setting group for the whole project, with limits set on per-company voting power Technical advisory groups: can now be formed to address specific topics where expertise and recommendations are required Maintainer lifecycle: clear definition of how project members move from contributor to maintainer and from retiring to emeritus status Decision-making and voting: clear rules on lazy consensus by default, and how votes should be conducted.\nFor feedback or questions please contact us through #falco on the Kubernetes Slack or the developer mailing list.\nIf you are interested in joining the community, you can find out how to contribute in Contribution Guidelines.\nThank you to all the Falco maintainers and community members for their discussion and support as we improved our governance documentation!\nFalco maintainers\n","summary":"","tags":["Community"],"title":"Updating Falco’s governance documentation","url":"https://v0-43--falcosecurity.netlify.app/blog/updating-falco-governance/"},{"category":"blog","content":"In this article, you will learn how Giant Swarm simplifies the maintenance of the software stack within Kubernetes clusters by using its App Platform technology. Additionally, we will show how customers can leverage this to easily deploy Falco, either individually or as part of Giant Swarm's Security Pack, to secure their managed Kubernetes service.\nGiant Swarm Having CoreOS, Fleet, and Docker as base technologies, Giant Swarm was founded in 2014. In 2016, it chose Kubernetes to reinvent itself. And just a year later, in 2017, it became part of the founding members of the Kubernetes Certified Service Providers. Customers like Adidas or Vodafone backup a company that, supported by a fully remote team, has been able to foresee the trends of technology and working lifestyle.\nAs a managed Kubernetes company, its services and infrastructure enable enterprises to run resilient distributed systems at scale while removing the burden of Day 2 operations. Giant Swarm takes pride in delivering a fully open source platform that's carefully curated and opinionated.\nSecurity and simplicity Giant Swarm takes security as seriously as ease of management. Hence, when using a managed Kubernetes platform, everything that happens on the management cluster is as important as the performance of the workload cluster itself.\nThat's why, leveraging the concept of operators to control all resources that clusters need as 'Custom Resources', Giant Swarm can deploy and update its management clusters in the quickest possible way. Needless to say, this is exactly what Giant Swarm offers to its customers to manage their applications.\nFalco, the Runtime Security Project Falco is the de facto Kubernetes threat detection engine, and also extends its reach to cloud and Linux hosts. It monitors the behavior of every process in the node and can alert us when something fishy happens.\nHow does Falco do that? Based on a set of rules that Falco interprets at startup time, it waits for events and syscalls that would trigger one of those rules. When a rule is triggered, Falco raises an alert and, thanks to applications like Falco Sidekick, allows teams to react accordingly.\nBut with great power comes great responsibility. What happens when we start getting false positives our Falco rules haven't been updated for some months, or our Falco daemon is a few versions behind? The answer is as simple as updating. Well, maybe not that simple if we are responsible for tens of clusters with hundreds of nodes.\nGiant Swarm App Platform Giant Swarm describes App Platform as a set of features that allow you to browse, install, and manage the configurations of managed apps from a single place: The management cluster.\nThe technology behind it is simple: Apps are packaged as Helm charts, can be configured with values, overridden with a different app configuration, etc. - whatever meets your needs. To deploy, a CRD (Custom Resource Definition) resource is created, interpreted by the App Operator (running on the managed cluster), assigned to the Chart Operator (running on the workload cluster), and in a few seconds, our application will be deployed on as many clusters as desired.\nThe App Platform offers its repertoire of applications from the App Catalog. Giant Swarm offers two App Catalogs out of the box: The Giant Swarm Catalog and the Giant Swarm Playground. But what we love the most from the App Platform is that we can have our additional catalogs, storing our applications and configurations.\nWhat does it look like on the CLI? It's now time to look at App Platform running. Let's walk through its deployment on a minikube cluster. Following these instructions, it shouldn't take too long until we are ready to deploy our first managed app, Falco, using a single CRD.\nTo keep this as standard as possible, we'll even go through some steps to compile some interesting Giant Swarm tools, like the plugin kubectl-gs.\nDo you already have a Kubernetes cluster nearby? If not, we can spin up a minikube instance pretty quickly.\n$ minikube start --driver virtualbox 😄 minikube v1.25.1 on Darwin 11.6.6 ✨ Using the virtualbox driver based on user configuration 👍 Starting control plane node minikube in cluster minikube 🔥 Creating virtualbox VM (CPUs=2, Memory=6000MB, Disk=20000MB) ... 🐳 Preparing Kubernetes v1.23.1 on Docker 20.10.12 ... ▪ kubelet.housekeeping-interval=5m ▪ Generating certificates and keys ... ▪ Booting up control plane ... ▪ Configuring RBAC rules ... ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5 🔎 Verifying Kubernetes components... 🌟 Enabled addons: default-storageclass, storage-provisioner 🏄 Done! kubectl is now configured to use \u0026#34;minikube\u0026#34; cluster and \u0026#34;default\u0026#34; namespace by default If you don't have kubectl installed or your system, the easiest way to access it would be through an alias to minikube kubectl, like this:\nalias kubectl=\u0026#34;minikube kubectl --\u0026#34; Don't forget the -- at the end. That tells the command prompt not to pass any added parameters to minikube, since we need them to be understood by kubectl.\nOne disadvantage of this method, in comparison to having a local kubectl binary, is that the kubectl-gs plugin might not work when called as kubectl gs (explained later during this tutorial) so you might need to call it directly.\nTo ensure our cluster is up and running, execute the following command and verify that all nodes, pods, and containers are up and ready:\n$ kubectl get nodes,ns,pods -A NAME STATUS ROLES AGE VERSION node/minikube Ready control-plane,master 4m16s v1.23.1 NAME STATUS AGE namespace/default Active 4m14s namespace/kube-node-lease Active 4m15s namespace/kube-public Active 4m15s namespace/kube-system Active 4m16s\nNAMESPACE NAME READY STATUS RESTARTS AGE kube-system pod/coredns-64897985d-qbf4n 1/1 Running 0 4m kube-system pod/etcd-minikube 1/1 Running 0 4m12s kube-system pod/kube-apiserver-minikube 1/1 Running 0 4m12s kube-system pod/kube-controller-manager-minikube 1/1 Running 0 4m12s kube-system pod/kube-proxy-6ds89 1/1 Running 0 4m kube-system pod/kube-scheduler-minikube 1/1 Running 0 4m14s kube-system pod/storage-provisioner 1/1 Running 1 (3m29s ago) 4m10s Prerequisites: Compiling apptestctl and kubectl-gs\nAs mentioned above, we'll compile a couple of tools. The first one will be apptestctl. This tool will help us bootstrap App Platform on a cluster not managed by Giant Swarm.\nTo do this, we'll use the docker.io/golang:1.17 image.\nThe following command will prepare an available instance of a Golang compiler for us to compile both of these tools:\n$ kubectl run golang --image docker.io/golang:1.17 -- sleep infinity pod/golang created Compiling apptestctl These steps are quite simple: clone the apptestctl repository and compile it as indicated.\nWe'll do this inside the container we created in the previous step so we don't pollute our system.\n$ kubectl exec -it golang -- git clone https://github.com/giantswarm/apptestctl src/apptestctl Cloning into \u0026#39;apptestctl\u0026#39;... ... output omitted ... Resolving deltas: 100% (791/791), done. $ kubectl exec -it golang -- make -C src/apptestctl make: Entering directory '/go/src/apptestctl' ... output omitted ... ====\u0026gt; apptestctl-v-linux-amd64 ... output omitted ... cp -a apptestctl-v-linux-amd64 apptestctl ====\u0026gt; build make: Leaving directory '/go/src/apptestctl' Alternatively, you can build a Darwin client.\n$ kubectl exec -it golang -- make build-darwin -C src/apptestctl make: Entering directory \u0026#39;/go/src/apptestctl\u0026#39; ... output omitted ... ====\u0026gt; apptestctl-v-darwin-amd64 ... output omitted ... cp -a apptestctl-v-darwin-amd64 apptestctl-darwin ====\u0026gt; build-darwin make: Leaving directory \u0026#39;/go/src/apptestctl\u0026#39; Either way, you can copy the apptestctl binary to your system and use it from wherever you prefer.\n$ kubectl cp golang:/go/src/apptestctl/apptestctl-darwin ./apptestctl $ kubectl chmod u+x ./apptestctl Compiling kubectl-gs Use the same steps to compile the kubectl-gs plugin this time, which will allow us to interact with App Platform. Pay attention to the fact that we'll compile it just for Darwin in this instance.\n$ kubectl exec -it golang -- git clone https://github.com/giantswarm/kubectl-gs src/kubectl-gs Cloning into \u0026#39;kubectl-gs\u0026#39;... ... output omitted ... Resolving deltas: 100% (4427/4427), done. $ kubectl exec -it golang -- make build-darwin -C src/kubectl-gs make: Entering directory '/go/src/kubectl-gs' ... output omitted ... ====\u0026gt; kubectl-gs-v-darwin-amd64 ... output omitted ... cp -a kubectl-gs-v-darwin-amd64 kubectl-gs-darwin ====\u0026gt; build-darwin make: Leaving directory '/go/src/kubectl-gs'\n$ kubectl cp golang:/go/src/kubectl-gs/kubectl-gs-darwin ./kubectl-gs $ kubectl chmod u+x ./kubectl-gs Deploying App Platform via apptestctl\nOnce we have both tools, apptestctl and kubectl-gs, it's time to bootstrap App Platform. To do that, we'll use the apptestctl bootstrap command.\nThe command apptestctl bootstrap needs the KUBECONFIG information to access our minikube cluster, so in this case, we will use the command kubectl config view --flatten --minify -o json to obtain it.\nAlternatively, we would need to look for the .kube/config file and pass it with the --kubeconfig-path option.\n$ ./apptestctl bootstrap --kubeconfig \u0026#34;$(kubectl config view --flatten --minify -o json)\u0026#34; bootstrapping app platform components ... output omitted ... app platform components are ready Once deployed, we can run a few commands to observe the resources created in our cluster.\n$ kubectl get deployments -n giantswarm NAME READY UP-TO-DATE AVAILABLE AGE app-operator 1/1 1 1 1m20s chart-operator 1/1 1 1 1m20s chartmuseum-chartmuseum 1/1 1 1 1m20s kubectl get catalog -A NAMESPACE NAME CATALOG URL AGE default chartmuseum http://chartmuseum-chartmuseum:8080/charts/ 1m25s default helm-stable https://charts.helm.sh/stable/packages/ 1m25s Wait a moment... Where does this Catalog resource come from? The bootstrap process of App Platform creates some CRDs that will support the operators to manage our applications.\n$ kubectl get crd NAME CREATED AT appcatalogentries.application.giantswarm.io 2022-06-10T15:30:12Z appcatalogs.application.giantswarm.io 2022-06-10T15:30:12Z apps.application.giantswarm.io 2022-06-10T15:30:12Z catalogs.application.giantswarm.io 2022-06-10T15:30:12Z charts.application.giantswarm.io 2022-06-10T15:30:12Z In short, once we register a Catalog, several AppCatalogEntries resources will be created. There will be at least one per application and version.\nRegistering a Catalog Now, it looks like a great time to see what the kubectl-gs plugin can do for us.\n$ kubectl-gs get catalogs NAME NAMESPACE CATALOG URL AGE chartmuseum default http://chartmuseum-chartmuseum:8080/charts/ 25m helm-stable default https://charts.helm.sh/stable/packages/ 25m All right, that was maybe not so impressive, but it'll become much more useful when we register our first catalog. Why is that? Because kubectl gs will help us generate the definition of a Catalog resource through its template subcommand.\n$ kubectl-gs template catalog --name giantswarm --namespace default \\ --description \u0026#34;Giant Swarm Catalog\u0026#34; --logo http://logo-url \\ --url https://giantswarm.github.io/giantswarm-catalog --- apiVersion: application.giantswarm.io/v1alpha1 kind: Catalog metadata: name: giantswarm labels: application.giantswarm.io/catalog-visibility: public namespace: default spec: title: giantswarm description: Giant Swarm Catalog logoURL: http://logo-url storage: URL: https://giantswarm.github.io/giantswarm-catalog type: helm Et voilà, our Catalog CRD pointing to a Giant Swarm collection of applications is ready to be deployed into our cluster.\nYou might have figured out already what each parameter represents. kubectl gs will complain if any of those parameters are missing. Also, pay attention that we didn't use a real logo URL, but if you were using happa, the Giant Swarm Web-UI, would't you like to see a logo identifying your application?\nFinally, the URL is the location of the Helm repository from which App Platform will download the applications.\nOnce we understand what the kubectl gs template command has generated, it's time to create it inside the cluster and let the App Operator do its magic. Let's go for it.\n$ kubectl-gs template catalog --name giantswarm --namespace default \\ --description \u0026#34;Giant Swarm Catalog\u0026#34; --logo http://logo-url \\ --url https://giantswarm.github.io/giantswarm-catalog | kubectl apply -f - catalog.application.giantswarm.io/giantswarm created $ kubectl-gs get catalogs NAME NAMESPACE CATALOG URL AGE chartmuseum default http://chartmuseum-chartmuseum:8080/charts/ 35m helm-stable default https://charts.helm.sh/stable/packages/ 35m giantswarm default https://giantswarm.github.io/giantswarm-catalog 53s\n$ kubectl gs get catalog giantswarm CATALOG APP NAME VERSION UPSTREAM VERSION AGE DESCRIPTION ... output omitted ... giantswarm falco-app 0.3.2 0.0.1 5m26s A Helm chart for falco ... output omitted ... Do you remember the aforementioned AppCatalogEntries that the App Operator had to create once we defined the Catalog? Here are the Falco ones.\n$ kubectl get AppCatalogEntries | grep falco-app giantswarm-falco-app-0.1.2 giantswarm falco-app 0.1.2 0.0.1 240d giantswarm-falco-app-0.2.0 giantswarm falco-app 0.2.0 0.0.1 176d giantswarm-falco-app-0.3.0 giantswarm falco-app 0.3.0 0.0.1 103d giantswarm-falco-app-0.3.1 giantswarm falco-app 0.3.1 0.0.1 94d giantswarm-falco-app-0.3.2 giantswarm falco-app 0.3.2 0.0.1 79d Installing an App from the App Catalog What we've done so far was deploy App Platform, which is required only once. Giant Swarm would have configured that for us already if we were using their services.\nNow, it's finally time to create the CRD that will trigger the App Operator to assist in the deployment of Falco. How do we do that? kubectl gs comes to the rescue again!\n$ kubectl gs template app --catalog giantswarm --name falco-app --namespace falco-ns --version 0.3.2 --app-name my-falco --in-cluster --- apiVersion: application.giantswarm.io/v1alpha1 kind: App metadata: name: my-falco labels: app-operator.giantswarm.io/version: 0.0.0 namespace: falco-ns spec: name: falco-app version: 0.3.2 namespace: falco-ns kubeConfig: inCluster: true catalog: giantswarm It is worth mentioning that we are testing on a minikube cluster, where we install applications inside the cluster itself. To achieve that, we use the --in-cluster parameter passed to the previous commands.\nOtherwise, if we wanted to install or update the application in one of our managed workload clusters, we would use the --cluster parameter to indicate where the application should be deployed:\n$ kubectl gs template app --catalog giantswarm --name falco-app --namespace falco-ns \\ --version 0.3.2 --cluster cluster-123 --app-name my-falco --- apiVersion: application.giantswarm.io/v1alpha1 kind: App metadata: name: my-falco namespace: cluster-123 spec: name: falco-app version: 0.3.2 namespace: falco-ns kubeConfig: inCluster: false catalog: giantswarm In the previous output, you can see how the namespace field inside the metadata section receives the name of the cluster instead of the actual namespace where the application should reside.\nThe reason is that, although the application will be installed on one of the workload clusters, this CRD will be created in a namespace inside the management cluster. This topic alone would be enough for a whole new post.\nHere is a graphical representation of the CRDs supporting App Platform, in the management cluster:\nFinally, the last step is creating the CRD for the App in the cluster. Don't forget to ensure that the namespace where the CRD will belong exists, or the kubectl apply command will fail.\n$ kubectl create ns falco-ns namespace/falco-ns created $ kubectl gs template app --catalog giantswarm --name falco-app --namespace falco-ns --version 0.3.2 --in-cluster --app-name my-falco | kubectl apply -f- app.application.giantswarm.io/my-falco created\n$ kubectl gs get app -n falco-ns NAME VERSION LAST DEPLOYED STATUS NOTES my-falco 0.3.2 113s deployed\nHere are the resulting Kubernetes resources when using regular kubectl commands.\n$ kubectl get app,deployment,daemonset -n falco-ns NAME INSTALLED VERSION CREATED AT LAST DEPLOYED STATUS app.application.giantswarm.io/my-falco 0.3.2 4m25s 4m24s deployed NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/my-falco-falcosidekick 2/2 2 2 4m24s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/my-falco 1 1 1 1 1 \u0026lt;none\u0026gt; 4m24s daemonset.apps/my-falco-falco-exporter 1 1 1 1 1 \u0026lt;none\u0026gt; 4m24s The previous output might differ depending on the type of cluster you would be using, among other variables.\nAs you can see, once App Platform is up and running, we only need to create the namespace that should contain the Falco application (which should already exist if we are deploying from a managed workload cluster), and the CRD based on the template from the kubectl gs plugin. In a matter of seconds, Falco will be up and running, watching for threats and alerting when suspicious behaviors arise.\nManaged Security Zach Stone, Platform Engineer at Giant Swarm, walked us through some of the biggest challenges that the company's customers face and how his team is using Falco to develop thoughtful solutions.\n“The biggest problem that most of our customers face isn't what happens in the cluster, it's what happens with the information once they get it out of the cluster,” asserted Stone. “People also focus too much on the capability that a tool offers and don't take a bigger look at the security processes it supports.”\n“If a customer has a vulnerability management program, we can track all of the vulnerabilities in their components, but if fixing those vulnerabilities isn’t a priority, then the program doesn’t work,” remarked Stone. \u0026quot;The larger discussion is usually about where the alerts should go, who bears responsibility for remediation, and how to fit that work into the team's limited capacity. We spend a lot of time trying to ensure security isn't just something that sits alongside the business, but rather is a meaningful part of the daily routine.\u0026quot;\nPart of that effort is in tuning detection rules and alerting. \u0026quot;Any time we surface an alert, it should be actionable and have a clear owner who is invested in never seeing that alert again.\u0026quot;\n“I think Falco's superpower is in the flexibility of the policies. I'm also really excited about the changes that are slated to make it easier to update them. Most rules aren't one-size-fits-all -- for a given policy, there is usually some refinement needed to ensure the policy makes sense within our platform, and then customers modify it even further to meet their security requirements. All that customization can make it incredibly difficult to reconcile,” said Stone. “The fact that we can already do it with Falco speaks volumes about the versatility of the solution.”\nSecurity Pack Giant Swarm's Security Pack is a collection of open source security tools offered by Giant Swarm, which not only contains Falco but also a plethora of other open source projects, including Kyverno for policy enforcement, Trivy for image scanning, and Cosign for image signature verification.\nSecurity does not apply to a single level and, therefore, Security Pack consists of multiple applications, each one independently installable and configurable, available via their App Platform. “Falco will be the cornerstone of our node-level security capabilities,” affirmed Stone, “the biggest opportunity for API plug-ins I see is to get feedback from the node level back into the Security Pack so that we can further contextualize events in the ecosystem.”\nConclusion Adding simplicity to our cluster management is considered a requirement nowadays, especially in those cases where the lack of resources in an organization can keep it from achieving an acceptable level of security.\nFeatures like Giant Swarm's App Platform and Security Pack will help organizations to finally focus on what actually matters to them: Running their business. In the future, Giant Swarm plans to launch its security pack across all its customers' clusters, enabled by default and built on Falco.\n","summary":"","tags":["Falco","Integration","User Story"],"title":"Manage Falco easier with Giant Swarm App Platform","url":"https://v0-43--falcosecurity.netlify.app/blog/giantswarm-app-platform-falco/"},{"category":"blog","content":"Today we announce the release of Falco 0.32.2 🦅!\nNovelties 🆕 This release is really small, like a little 🐦, it only fixes the URL to download the falco BPF probe from Falco download page. A big thank you goes to eric-engberg, who proposed the fix, and as usual to everyone in the community for helping us in spotting these annoying bugs 🐛! You make Falco successful 🦅!\nThanks as always to the Falco maintainers for their support and effort during the entire release process.\nFixes 🐛 This release fixes just one bothersome bug:\nThe url from which Falco tryes to download the BPF probe was wrong, eric-engberg proposed the solution in this PR. Thank you again! 🙏 Try it! 🏎️ As usual, in case you just want to try out the stable Falco 0.32.2, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader What's next 🔮 It's an exciting time for Falco as we see so many great improvements and features. What's more exciting is the fact that there are many great ideas and awesome work going on to make the next big things happen.\nRecently, there has been a lot of interest on the shiny new eBPF probe, making use of modern eBPF features like CO-RE, ringbuffer API and new tracing program.\nIn addition, many people in the community are interested in using Falco to read syscall events and plugin events simultaneously. If you are, I would suggest to take a look at the in-depth design for this new feature!\nLet's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nAndrea\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.32.2","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-32-2/"},{"category":"blog","content":"Today we announce the release of Falco 0.32.1 🦅!\nNovelties 🆕 A bit more than a month has passed since the last release, and we already have 84 new commits in Falco (bringing the falcosecurity/falco repo to an even and eye pleasing total of 3,000 commits 😎) and a massive 215 commit changelog in libs!\nA big THANK YOU 💖 goes as usual to everyone in the community for working on that many features and especially to those that are willing to test them even before release! You make Falco successful 🦅! Thanks as always to the Falco maintainers with their relentless work reviewing PRs and making sure the release process works smoothly.\nLet's review some of the highlights of the new release.\nWhat's new? First of all, this new version comes with out of the box support for two technologies that were already partially or internally supported in previous versions and they're now getting the complete feature set they deserve, plus some minor CLI and configuration changes and under-the-hood improvements.\nOfficial ARM AArch64 Packages and Images 🚀: you read it right! By popular demand, we now have official AArch64 support! It's hard to overstate the community effort that was required to make this happen, as the necessary changes span across multiple repos and touch pretty much all the components that make Falco work, including:\nfalcosecurity/falco with a ton of work by Federico Di Pierro to properly build Falco and create shiny new artifacts and images to make installation easy! falcosecurity/libs thanks to Andrea Terzolo and Federico for adding kernel and eBPF support to this new architecture which, surprise surprise, behaves differently than x86_64 sometimes in really unexpected ways that are tricky to handle; falcosecurity/test-infra and falcosecurity/driverkit thanks to David Windsor, Federico, maxgio92 and Michele Zuccala we now have proper infrastructure to build multi platform drivers and eBPF probes, now available in the download.falco.org repository! gVisor support and relevant CLI options 🌕: gVisor is an application kernel for containers that provides efficient defense-in-depth anywhere. When using gVisor, in order to limit the attack surface of the host, each container is provided with its own application kernel. Normally, Falco would be unable to work in such environments since kernel modules or eBPF probes may not be installed within those sandboxes. Recently, the gVisor team developed a feature that allows security software to receive and audit syscalls that are executed by sandboxed containers; Falco can then use this stream of syscalls as a data source and monitor gVisor systems with the same rulesets as it normally would use. The relevant CLI options --gvisor-config, --gvisor-generate-config and --gvisor-root have been added for this purpose. Stay tuned for more information about how to make Falco and gVisor work together! I had the pleasure to work on this along with Lorenzo Susini. Thanks a lot to the gVisor team for their help!\nIf you are interested in the Falco libraries and drivers you will be happy to know that both libs and drivers are now versioned. In fact, this release uses libs version 0.7.0 and driver 2.0.0. Refer to the libs readme for more information about versioning strategies and release processes.\nThis release introduces some minor changes in the configuration, adding libs_logger.enabled and libs_logger.severity to be able to read libs logs which would otherwise be hidden from the user. The default behavior does not change but those options could be useful for troubleshooting and development.\nAlso, you can now see additional information about any configured plugin with the new --plugin-info CLI option.\nVery worth mentioning is the big refactor that is going on in libscap (part of the falco libs) to make it easier to support different types of syscall sources. gVisor support leverages this feature, as the next big things most likely will.\nNew syscalls The support for the dup family of syscalls has been enhanced, and also support for dup2 and dup3 is now available.\nFixes Multiple bugs were fixed:\nfixed incorrect behavior of the -V option when validating rules files; fixed issues when loading kernel module with DKMS on Flatcar Linux and supporting fetching pre-built module/eBPF probe ...and much more of course, many of which are listed in the libs 0.7.0 release notes.\nNot really a bug fix from previous releases but I'd like to add a shout out to Mauro Moltrasio for catching bugs early in reviews and also finding and fixing a tricky stability bug in the integration code for gVisor that was affecting the whole Falco, just right after I committed it!\nSecurity Content 🔒 The default signature algorithm for the RPM package is now RSA/SHA256; Bundled dependencies were upgraded, namely openssl to 1.1.1p and libcurl to 7.84.0. Default rules update 🛡️ This release also includes updates to the default ruleset: 👇\nRedirect STDOUT/STDIN to Network Connection in Container Moreover, new rules were added: 👇\nJava Process Class Download: detect potential log4shell exploitation Try it! As usual, in case you just want to try out the stable Falco 0.32.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader What's next 🔮 It's an exciting time for Falco as we see so many great improvements and features. What's more exciting is the fact that there are many great ideas and awesome work going on to make the next big things happen.\nRecently, there has been a lot of interest on the shiny new eBPF probe, making use of modern eBPF features like CO-RE, ringbuffer API and new tracing program.\nIn addition, many people in the community are interested in using Falco to read syscall events and plugin events simultaneously. If you are, I would suggest to take a look at the in-depth design for this new feature!\nLet's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nCheers 🎊\nLuca\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.32.1","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-32-1/"},{"category":"blog","content":"Today we announce the release of Falco 0.32.0 🦅!\nNovelties 🆕 Let's review some of the highlights of the new release. This is one of the biggest releases ever, with around 200 commits on Falco and 230 on libs.\nThe Falco community once again proved to be super active, and we wanted to say a huge THANK YOU 🙏 💖 to everyone involved.\nNew features This new release comes with a ton of inner rework; let's start with the foremost important change: Lua is no more a dependency of Falco! Ok, calm down now. Basically, the Falco rule loader was rewritten in C++, to achieve better performance. Moreover, the entire rule engine has been rewritten too.\nThis work reduces the workarounds in Falco, as it is now fully using libsinsp-provided filter parsers and compiler; finally, the new grammar fixes many minor and not-so-minor bugs.\nThanks to Jason Dellaluce for his amazing work!\nAnother effort by Jason was the porting of K8s Audit Log support to a plugin; consequently, there is no K8s Audit Log related code in Falco anymore.\nMoreover, a new --list-syscall-events CLI option is now available, to print list of supported syscalls.\nUsers and groups management is now dynamic: newly added users/groups will be properly fetched by Falco. On host, their full informations will be retrieved; instead, on containers, only the uid and gid will be retrieved as there is no stable API to fetch user/group info. Moreover, Falco won't mix host and container users anymore.\nAnother big refactor happened on how Falco handles its CLI and config options, with the concept of \u0026quot;app actions\u0026quot;. While this has no user facing changes, it is a big and noteworthy change.\nFalco is now able to detect changes to ruleset or config file, and automatically restart itself. This behavior is enabled by default.\nTwo new operators were developed: bcontains and bstartswith. These are useful to perform byte matching on events raw data.\nIt allows better detection for log4shell like vulnerabilities.\nFinally, all the Falco CI that is not involving any output artifact, has been ported to github actions. This frees up credits for CircleCI builds, mitigating various CI issues; moreover, it is now quicker.\nNew syscalls As always, hard work was also spent on hardening the system, supporting new syscalls:\nio_uring family of syscalls mlock family of syscalls capset syscall open_by_handle_at syscall Increased maturity of plugins Plugins API reached stable 1.0.0, with tons of work to improve the API and its performance, eventually fixing any bug encountered. It means that the contract is now stable and you can start developing your own plugin; we eagerly wait for it!\nGO Plugin Sdk was updated and all plugins were ported to new sdk.\nMoreover, with this release, plugin related rules are shipped together with their plugin.\nA couple of new plugins are now officially supported:\nokta plugin github plugin And more came from the community:\ndocker plugin seccompagent plugin We are really pleased to see new plugins coming; hopefully Plugin API 1.0.0 will give it a boost!\nFixes Multiple bugs were fixed:\na bug that caused Falco memory usage to skyrocket was solved. We are sorry for the inconvenience. multiple issues with container events were fixed. number of reported drops was mistakenly doubled while using the eBPF probe. This is now fixed. multiple eBPF verifier issues were solved, resulting in a much more resilient probe. ...and much more!\nSecurity Content 🔒 Bundled dependencies were upgraded, namely openssl to 1.1.1o and libcurl to 7.83.1, fixing a ton of CVEs!\nMoreover, gRPC was also bumped to 1.44.0.\nRules update 🛡️ This release also includes updates to the default ruleset: 👇\nInclude .ash_history in rule: Delete or rename shell history rule(Anonymous Request Allowed): exclude {/livez, /readyz} rule(k8s): secret get detection for both successful and unsuccessful attempts rules: whitelist GCP's container threat detection image Fixed ouput Rules K8s Serviceaccount Created/Deleted rule(falco_rules) Removed use cases not triggering macro curl_download rule(Disallowed K8s User): exclude allowed eks users Add user_known_mount_in_privileged_containers macro Allow to whitelist shell config modifiers Moreover, new rules were added: 👇\nNew Rule Detect Linux Cgroup Container Escape Vulnerability (CVE-2022-0492) new(rules): add rule to detect excessively capable container rules: detect pods sharing host pid and IPC namespaces Try it! As usual, to try out the stable Falco 0.32.0, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader What's next 🔮 Don't worry, we are still very hungry for improvements!\nCurrent work is involving arm64 support (https://github.com/falcosecurity/falco/pull/1997, https://github.com/falcosecurity/falco/pull/1990, https://github.com/falcosecurity/driverkit/pull/143), gvisor event source support, and libs versioning with proper tags.\nMoreover, a proposal for a shiny new eBPF probe was merged, and we anticipate the new probe will come to life very soon!\nIt will make use of modern eBPF features like CO-RE, ringbuffer API and new tracing program; together, these features will relax our support matrix while boosting performances.\nFinally, maintainers are discussing about releasing a patch release (0.32.1), once arm64 support is complete.\nWe will keep you posted!\nIn the end, as always, the best is yet to come 😉\nLet's meet 🤝 We meet every week in our community calls, if you want to know the latest and the greatest you should join us there!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nEnjoy! 🥳\nFederico\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.32.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-32-0/"},{"category":"blog","content":"A few days ago was the KubeCon EU in Valencia, Spain. The moment to meet contributors who made what Falcosidekick is now was a really enjoyable time and I hope we'll do it again in the future. One week before, two new major versions of Falcosidekick and Falcosidekick-Ui were released. Let's see what's new.\nFalcosidekick Almost 10 months without a new release for Falcosidekick, the version 2.25.0, and what a huge release is. For curious people, the full changelog can be found here.\nNew outputs Each new release brings more outputs, thanks to the community. Here's the list of new ones:\nPolicy Report With some CRD, you can now create reports in your Kubernetes clusters, the feature is often used for Security or Compliance, but anything is technically possible. For more details about how to use this output, read the documentation from @anushkamittal20 who implemented it for her project for Linux Foundation Mentorship Program.\napiVersion: wgpolicyk8s.io/v1alpha2 kind: ClusterPolicyReport metadata: creationTimestamp: \u0026#34;2022-05-23T13:57:40Z\u0026#34; generation: 110 name: falco-cluster-policy-report-4c9eac68 resourceVersion: \u0026#34;71090\u0026#34; uid: ed8f0659-74d5-488c-90f8-d7b0622738cf results: - category: SI - System and Information Integrity message: Cluster Role Binding to cluster-admin role (user=%ka.user.name subject=%ka.req.binding.subjects) policy: Attach to cluster-admin Role properties: ka.req.binding: \u0026#39;%ka.req.binding\u0026#39; ka.user.name: \u0026#39;%ka.user.name\u0026#39; result: fail severity: high source: Falco timestamp: nanos: 98821031 seconds: 40 - category: SI - System and Information Integrity message: Created Role/ClusterRole with write privileges (user=%ka.user.name role=%ka.target.name rules=%ka.req.role.rules) policy: ClusterRole With Write Privileges Created properties: ka.req.role: \u0026#39;%ka.req.role\u0026#39; ka.target.name: \u0026#39;%ka.target.name\u0026#39; ka.user.name: \u0026#39;%ka.user.name\u0026#39; result: fail severity: high source: Falco timestamp: nanos: 103148849 seconds: 42 The reports can also be displayed with Policy Reporter UI, created by @fjogeleit another member of the Falco community.\nSyslog Years after its creation, Syslog remains a solid solution for managing the log files, especially if you're running Falcosidekick or else directly at the host level. With this new version, a Syslog server can be directly used as the target for the events, allowing you to send them in a secure place. Thanks to @bdluca.\nAWS Kinesis Do you want to ingest thousands of events from Falco and be able to run data analysis on them? You can do so smoothly with the new AWS Kinesis output, bringing a new integration of Falco with AWS Ecosystem. We would be delighted to know any use case with analytics the community could create now. Thanks to @gauravgahlot.\nZoho Cliq Your DevOps/SRE/SecOps team uses Zoho Cliq for their communication? Allow them to receive nice notifications with this new output for Falcosidekick. Thanks to @averni.\nEnhancements Getting new features is nice, but we can also improve the existing ones, here's a list of major changes of this 2.25.0 release.\nCompiled ans signed binaries Until then, if you wanted binaries of Falcosidekick, you had to build them by yourself or use the provided Docker image. Now, each release will contain the compiled binaries for amd64 and arm64. The security is not forgotten, all artifacts are signed with Cosign.\nTags and Source In January, Falco 0.31.0 brought its new Plugin system, the source field of events becoming more important. This new release of Falcosidekick updates all the outputs to deal with source and tags events. Your Response Engines can now be much clever than even.\nIRSA IRSA, aka Iam Role for Service Accounts, is the method provided by AWS for linking a Kubernetes Service Account with an IAM Role, allowing the Pod to easily use a Service. Falcosidekick is now able to use this mechanism for its outputs for AWS Services, no need to add Access and Secret Keys in your values.yaml. The UX is much better. Thanks to @VariableExp0rt.\nFalcosidekick UI I created the first version v0 of Falcosidekick-UI to have something more graphical for my talks, with the help of @fjogeleit we created a nice v1 that has been finally used more and more by people, becoming a famous product in the community. It was time to have a better version with some requested features:\na database (Redis) for a long term storage of events an API for counting or searching the events filters are kept as query strings, allowing to share links All details to use this new version, v2.0.0, are described in the README.\nHere's some screenshots:\nDeployments The Helm charts are already up to date, you can upgrade your deployments with:\nhelm upgrade falcosidekick falcosecurity/falcosidekick --set webui.enabled=true -n falco or\nhelm upgrade falco falcosecurity/falco \\ --set falcosidekick.enabled=true \\ --set falcosdekick.webui.enabled=true -n falco Enjoy\nIf you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Release"],"title":"Falcosidekick 2.25.0 and Falcosidekick 2.0.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-2-25-0-falco-2-0-0/"},{"category":"blog","content":"Hello, Falcoers!\nInterested in Falco and want to contribute your ideas? Feeling stuck because you don't know where to start? No worries, we are here to help!\nWhether you want Falco to monitor a new system call, add a brand new feature, or solve a problem you ran into, you have to create a development environment. This blog post will walk you through the process of setting up a new one so that you can feel comfortable and ready to contribute!\nNow, let's go step by step, showing what is required to get started hacking on Falco. We hope this table of contents will facilitate the use of this post as a future reference.\nSetting up the environment Creating a dedicated VM Discovering the Falco code Building Falco from scratch Testing your build Falco Event-Generator Falco Test Suite Writing your own test rules Conclusion Setting up the environment A peculiarity of the Falco project is that you may need to write some kernel-level code. An important consideration to make, even before starting to code, is that the eBPF probe and the kernel module should provide exactly the same features.\nFor this reason, when developing something on the eBPF probe, you should implement the same functionality on the kernel module and vice versa, with the intent of preserving feature parity across the two drivers.\nWriting code at the kernel-level is not an easy task. In particular, the kernel module requires extra care because your code will run with full kernel privileges. Any little mistake may result in a kernel panic, crashing the system.\nOn the other hand, eBPF programs are much safer than the kernel module, but sometimes you may need to fight against the verifier on different kernel versions.\nFor these reasons, some of us find using Vagrant extremely helpful. Vagrant is a tool that allows you to easily spawn virtual machines, so that you can test your code against multiple kernel versions and Linux distributions without causing any harm to your system.\nCreating a dedicated VM If you have never used Vagrant before, you first need to download and install Vagrant and a Vagrant VM provider. You may want to install VirtualBox since Vagrant comes with out-of-the-box support. You can follow the Vagrant quickstart to accomplish this.\nOnce you can spawn VMs with Vagrant, choose a box from Vagrant Cloud containing your favorite distribution for development.\nFor instance, if you want to launch a Ubuntu Focal Fossa machine, you can issue the following commands:\n$ mkdir ubuntu-vm \u0026amp;\u0026amp; cd ubuntu-vm $ vagrant init ubuntu/focal64 $ vagrant up Vagrant initializes virtual machines so that you can easily access them via SSH. This helps in case you also want to try out remote development, for instance with Visual Studio Code. This way, you will be able to seamlessly code, build, and test on the Vagrant virtual machine!\nFrom now on, the command vagrant ssh will log you into the VM and you could start working right away. However, unless you prefer writing code on older (but very powerful) tools like Vim, you may feel the need to use an IDE, as if you were developing on your local machine.\nTo do so, we will show you how to extend Visual Studio Code capabilities by downloading the Remote - SSH extension. This extension lets you use any remote machine that allows SSH access as your development environment. This includes the VM you just spawned with Vagrant.\nAfter installing the extension, from inside the Vagrant VM directory, retrieve the SSH configuration:\n$ vagrant ssh-config Host default HostName 127.0.0.1 User vagrant Port 2222 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile /Users/lorenzo.susini/vagrant/official-ubuntu/.vagrant/machines/default/virtualbox/private_key IdentitiesOnly yes LogLevel FATAL Copy the output of the last command and paste it into the .ssh/config file in your local home directory. Also, we recommend changing the Host default line with something that helps you remember that this is the VM you use for developing Falco. Something like Host falco-dev would work.\nThen, go back to Visual Studio Code. Press Control + P (or Command + P on MacOS) and type \u0026gt; Remote-SSH: Connect to Host. Press Enter and you will see the falco-dev entry in the UI to connect to the VM. Your development environment is now up and running. You can open remote folders and projects, and use all the functionalities of Visual Studio Code!\nDiscovering the Falco code Now, it's time to have some fun. Falco's source code lives in the Falco organization on GitHub. The two repositories you should take a look at are:\nfalcosecurity/libs, containing both the kernel module and the eBPF probe, and also libscap and libsinsp. falcosecurity/falco, including the rule engine, rules, and support for any kind of output, such as standard output, file output, gRPC, and more. If you're not yet familiar with the overall Falco architecture, you can go into detail by reading the previous blog post.\nBuilding Falco from scratch Most of the time, the main starting point for developing something is building it from scratch. You can fork falco and libs, and clone them into your development machine. Forking the repositories first is recommended if you want to later push the changes and save your work.\nThen, try to follow the steps in our official Falco documentation. Some of the most useful CMake definitions you may want to use are:\n-DUSE_BUNDLED_DEPS=ON allows you to download and compile all the needed Falco dependencies. This also helps to build Falco independently of the libraries installed in your system. The build process will run trouble-free using this option, although it will be a little bit slower.\n-DFALCOSECURITY_LIBS_SOURCE_DIR=/path/to/local/libs allows you to compile Falco with a local version of libs. If not specified, CMake will download the libs repository directly from GitHub. This option is extremely handy when you are implementing something that requires modification to both falco and libs repositories so that you can easily test what you coded.\n-DBUILD_BPF=ON allows compilation of the eBPF probe, crucial when developing something on the eBPF driver.\n-DCMAKE_BUILD_TYPE=Debug is helpful when you want to debug something. Debug information is printed out and assertions are enabled.\nThe complete sequence of commands you may want to run is:\n$ mkdir build \u0026amp;\u0026amp; cd build $ cmake -DUSE_BUNDLED_DEPS=ON \\ -DFALCOSECURITY_LIBS_SOURCE_DIR=/path/to/local/libs \\ -DBUILD_BPF=ON \\ -DCMAKE_BUILD_TYPE=Debug .. $ make Also, note that you can use the -jxxx option of make to spawn multiple parallel jobs, where xxx is the number of jobs.\nTesting your build Now that you have successfully compiled Falco, try to run it. The default driver is the kernel module. To use it, assuming that you are in the build directory, just type:\n$ sudo insmod driver/falco.ko $ sudo ./userspace/falco/falco -c ../falco.yaml \\ -r ../rules/falco_rules.yaml To start Falco with the eBPF driver instead, you need to set the FALCO_BPF_PROBE environment variable, like this:\n$ sudo FALCO_BPF_PROBE=driver/bpf/probe.o ./userspace/falco/falco \\ -c ../falco.yaml -r ../rules/falco_rules.yaml Falco Event-Generator Now that you built Falco, you may wonder if everything works as expected. A quick and dirty way of testing Falco is using the event-generator.\nThis is yet another project from the Falcosecurity organization, and it can be used to generate some suspicious actions on the system, therefore, triggering some Falco rules.\nAll you need to do is to start two terminals. You will launch Falco from one of them and leave it running. From the second terminal, launch the event generator using the following command:\ndocker run -it --rm falcosecurity/event-generator run syscall If everything works fine, in the first terminal you opened you will see Falco alerting of some malicious behaviors from the container we started in the second one.\nFalco Test Suite You can also test Falco by using its own test-suite. The Falco test-suite uses the Avocado Framework to launch tests.\nAll you have to do is the following:\n$ cd falco/test $ ./run_regression_tests.sh -p -v $ virtualenv venv $ source venv/bin/activate $ pip install -r requirements.txt $ BUILD_DIR=\u0026#34;../build\u0026#34; avocado run --mux-yaml falco_traces.yaml \\ --job-results-dir /tmp/job-results -- falco_test.py $ deactivate The run_regression_tests.sh script downloads and prepares trace files needed for testing. Falco can consume these files containing some recorded system activity that must trigger rules.\nIf you want, you can also refer to the documentation to launch other kinds of tests, such as rule engine and k8s audit logs tests, just to name a few.\nYou can relaunch these tests whenever you add something to the codebase, just to make sure nothing got broken after you played around with it.\nYou are now ready to put your hands on Falco!\nWriting your own test rules At this point, let's say you have introduced a new syscall. A possible way to effectively test it is to write a custom rule. You can dig deeper on how to write rules by reading the related section in the official documentation.\nFalco's rule syntax is very simple and you will be able to write rules down very soon. A rule is made of:\nfield name field description rule name a short unique name for the rule description a longer description of what the rule detects condition a filtering expression that is applied against events to see if they match the rule output a message that should be produced if a matching event occurs priority severity associated with the rule To give you a little taste of writing rules, let's assume you have followed the aforementioned post where we added support for a new syscall. You would like to throw an alert every time a process executes it.\nYou could create a rule.yaml file having this as content:\n- rule: My test rule desc: Detects any process executing openat2 and prints its name and pid condition: evt.type = openat2 output: openat2 executed by (process name: %proc.name, pid: %proc.pid) priority: NOTICE Then, you can use the -r option to tell Falco to use this rule file. Of course, you can create much more complex and meaningful rules using many different fields and operators.\nConclusion You have learned how to set up a development environment with the help of Vagrant and Visual Studio Code, and how to build and run tests on Falco. You are now all set to dig into the source code, hack around, and unleash your creativity! We can't wait to see some of your PRs and build something great together!\nYou can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or just a friendly chat!\nIf you would like to find out more about Falco:\nGet started in Falco.org Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":null,"title":"Getting started developing Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/intro-development-falco/"},{"category":"blog","content":"In March 2022, the cybercriminal group LAPSUS$ claimed to have breached Okta, the Identity Platform, only two months earlier, leaving their customers with the uncertainty of having been exposed as well. After a thorough investigation undertaken by their security team, Okta made public some details of this security incident.\nOkta provides identity services for more than 15.000 companies. They guarantee that only legitimate personnel has access to networks and resources within their organization. This incident has raised once more the concern, that detecting suspicious events as soon as they occur within the organization is more necessary than ever.\nFalco has always excelled as a threat detection engine observing activity on Linux servers and Kubernetes clusters. Since Falco 0.31 it is also possible to collect events from sources other than Kernel Syscalls and Kubernetes Audit logs. The number of sources can be extended to cover any stream of events. For more information read our blogs posts about it:\nFalco Plugins Early Access Falco 0.31.0 a.k.a. \u0026quot;the Gyrfalcon\u0026quot; Announcing Plugins and Cloud Security with Falco Extend Falco inputs by creating a Plugin: the basics In this blog post, we'll introduce a new plugin created by the Falco Authors to collect Okta Log Events and be able to trigger alerts whenever suspicious events are detected.\nInstallation As with any other plugin created by the Falco Authors, you will find a library already built for a Linux environment in this URL.\nIt is a good practice to download the stable version and install it in the directory /usr/local/share/falco/plugins.\nHere are the steps to do so:\nsudo mkdir -p /usr/local/share/falco/plugins cd /tmp wget https://download.falco.org/plugins/stable/okta-0.1.0-x86_64.tar.gz tar xvzf okta-0.1.0-x86_64.tar.gz sudo mv libokta.so /usr/local/share/falco/plugins Configuration To activate the plugin for Falco, add the following configuration inside the plugin section of the file /etc/falco/falco.yaml like this:\nplugins: - name: okta library_path: /usr/local/share/falco/plugins/libokta.so init_config: organization: MYORG api_token: MY_API_TOKEN open_params: \u0026#39;\u0026#39; And enable it in the load_plugins section of the same file:\nload_plugins: [okta] Be aware that loading a plugin disables the syscalls collection. You may need to run a different instance of Falco service aside to collect both.\nOnly the following custom settings are required:\norganization: The name of your organization (same as in https://xxxx.okta.com) api_token: Your API Token to access Okta API. Follow the steps in the Okta Docs to know how to create one. Rules Available fields The plugin README lists all available fields to create your rules:\nName Type Description okta.app string Application okta.evt.type string Event Type okta.evt.legacytype string Event Legacy Type okta.severity string Severity okta.message string Message okta.actor.id string Actor ID okta.actor.Type string Actor Type okta.actor.alternateid string Actor Alternate ID okta.actor.name string Actor Display Name okta.client.zone string Client Zone okta.client.ip string Client IP Address okta.client.device string Client Device okta.client.id string Client ID okta.client.geo.city string Client Geographical City okta.client.geo.state string Client Geographical State okta.client.geo.country string Client Geographical Country okta.client.geo.postalcode string Client Geographical Postal Code okta.client.geo.lat string Client Geographical Latitude okta.client.geo.lon string Client Geographical Longitude okta.useragent.os string Useragent OS okta.useragent.browser string Useragent Browser okta.useragent.raw string Raw Useragent okta.result string Outcome Result okta.reason string Outcome Reason okta.transaction.id string Transaction ID okta.transaction.type string Transaction Type okta.requesturi string Request URI okta.principal.id string Principal ID okta.principal.alternateid string Principal Alternate ID okta.principal.type string Principal Type okta.principal.name string Principal Name okta.authentication.step string Authentication Step okta.authentication.sessionid string External Session ID okta.security.asnumber uint64 Security AS Number okta.security.asorg string Security AS Org okta.security.isp string Security ISP okta.security.domain string Security Domain okta.target.user.id string Target User ID okta.target.user.alternateid string Target User Alternate ID okta.target.user.name string Target User Name okta.target.group.id string Target Group ID okta.target.group.alternateid string Target Group Alternate ID okta.target.group.name string Target Group Name List of event types of interest Okta Security Team also proposes a list of event types of interest.\nUser Events EventType Filter Notes eventType eq \u0026quot;user.session.start\u0026quot; User logging in eventType eq \u0026quot;user.session.end\u0026quot; User logging out eventType eq “policy.evaluate_sign_on” Sign in policy evaluation eventType eq “user.account.lock” Okta user locked out eventType sw \u0026quot;user.authentication.auth\u0026quot; All types of Auth events, covering MFA, AD, Radius, etc eventType eq \u0026quot;user.account.update_password\u0026quot; User changing password eventType eq \u0026quot;user.authentication.sso\u0026quot; User accesing app via single sign on eventType eq \u0026quot;user.authentication.auth_via_mfa\u0026quot; MFA challenge eventType eq \u0026quot;user.mfa.factor.update\u0026quot; User changing MFA factors Okta Events EventType Filter Notes eventType eq \u0026quot;user.session.access_admin_app These events are associated with users accessing the Admin section of your Okta instance eventType eq \u0026quot;user.account.reset_password\u0026quot; User password reset by Okta Admin eventType eq \u0026quot;zone.update\u0026quot; Modification of a Network Zone eventType eq \u0026quot;user.account.privilege.grant\u0026quot; Granting Okta Admin to a user eventType eq \u0026quot;group.user_membership.add\u0026quot; Adding Okta user to a group eventType eq \u0026quot;application.user_membership.add\u0026quot; Adding user to application membership eventType eq \u0026quot;policy.lifecycle.create\u0026quot; Creation of a new Okta Policy eventType eq ”application.lifecycle.create” New Application created eventType eq ”user.lifecycle.activate” New Okta user eventType eq \u0026quot;application.provision.user.push\u0026quot; Assign application to user eventType eq ”user.lifecycle.deactivate” Deactivate Okta user eventType eq ”user.lifecycle.suspend” Suspend Okta user eventType eq \u0026quot;user.session.clear\u0026quot; Okta user login session cleared eventType eq \u0026quot;system.api_token.create\u0026quot; Creation of a new Okta API token eventType eq “system.org.rate_limit.violation” Hitting the rate limit on requests eventType eq “user.mfa.factor.deactivate” Removed MFA factor from user eventType eq \u0026quot;user.mfa.factor.reset_all\u0026quot; Remove all MFA factors from user Examples We can now easily create Falco rules to detect possible threats, e.g.:\n- rule: Adding user in OKTA group desc: Detect a new user added to an OKTA group condition: okta.evt.type = \u0026#34;group.user_membership.add\u0026#34; output: \u0026gt; \u0026#34;A user has been added in an OKTA group (user=%okta.actor.name, target group=%okta.target.group.name, target user=%okta.target.user.name)\u0026#34; priority: NOTICE source: okta tags: [okta] rule: User accessing OKTA admin section desc: Detect a user accessing OKTA admin section of your OKTA instance condition: okta.evt.type = \u0026quot;user.session.access_admin_app\u0026quot; output: \u0026gt; \u0026quot;A user accessed the OKTA admin section of your OKTA instance (user=%okta.actor.name, ip=%okta.client.ip)\u0026quot; priority: NOTICE source: okta tags: [okta] Notice the source: okta. It is mandatory to tell Falco these rules are related to the Okta plugin.\nYou can find the whole set of rules proposed by the Falco Authors among other rulesets in a PR in main Falco repository.\nRun Once the configuration and our rules are ready to be used, it's time to test it:\nfalco -c /etc/falco/falco.yaml -r /etc/falco/okta_rules.yaml You should get this kind of results:\n14:07:31.295984000: Notice A user has accessed an app using OKTA (user=Tony Stark, app=avengers_drive) 14:07:36.531283000: Notice A user has accessed an app using OKTA (user=Natasha Romanoff, app=shield_cloud) 14:08:24.077820000: Notice A user logged in OKTA from a suspicious country (user=Black Panther, ip=x.x.x.x, country=Wakanda) 14:09:22.064456000: Notice A user logged in OKTA from a suspicious country (user=Thanos, ip=x.x.x.x, country=Titan) Conclusion With the power of Falco and its new plugin framework, we've been able to consume events from a new source in just a few hours. This effort also aims to improve the observability of such an important element in the infrastructure of numerous organizations, as an Identity Provider like Okta is.\nFalco keeps demonstrating that it is much more than a runtime security project. It can support organizations by enabling their security teams to quickly detect and respond whenever a security incident occurs.\nYou can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or even for a friendly chat!\nIf you would like to find out more about Falco:\nGet started in Falco.org Plugin Documentation Plugin Developer Guide Plugin registry Check out the Falco project in GitHub Get involved in the Falco community Meet the maintainers on the Falco Slack Follow @falco_org on Twitter ","summary":"","tags":null,"title":"Analyze Okta Log Events with a Falco Plugin","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-okta-plugin/"},{"category":"blog","content":"Today we announce the release of Falco 0.31.1 🦅!\nNovelties 🆕 Let's review some of the highlights of the new release.\nNew features This release allows you to use multiple --cri command-line options (#1893) to specify multiple CRI socket paths. Note that Falco will only connect to the first one in order that successfully connects!\nSpeaking of command-line options, various changes are happening under the hood to improve the online help and to make it easier for contributors to add and modify options (#1886 #1903 #1915).\nThe update to the drivers version b7eb0dd brings in many improvements including proper detection of execveat, bugfixes for podman and support for the clone3 and copy_file_range system calls. In addition, the necessary extra arguments to entry system calls have been added to improve security of Falco event parsing as described below.\nSecurity Content 🔒 Falco is now more resilient to TOCTOU type attacks that could lead to rule bypass (CVE-2022-26316). For more information, read the security advisory. Thanks to Xiaofei 'Rex' Guo and Junyuan Zeng for reporting this issue!\nDefault rules update This release also includes modifications to the default ruleset, including a brand new rule to detect CVE-2021-4034 (Polkit Local Privilege Escalation) and false positive fixes (#1825, #1832)!\nTry it! As usual, in case you just want to try out the stable Falco 0.31.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader What's next 🔮 Falco 0.32.0 is anticipated to be released in May 2022!\nAs usual, the final release date will be discussed during the Falco Community Calls.\nLet'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!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors!\nEnjoy! 🎉🔒\nLuca\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.31.1","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-31-1/"},{"category":"blog","content":" This post is is part of a series of articles about How to develop Falco plugins. It's addressed to anybody who would like to understand how plugins are written and want to contribute. See other articles:\nExtend Falco inputs by creating a Plugin: the basics Extend Falco inputs by creating a Plugin: Distribute the plugin Introduction The registry Details of your plugin License ID Name Fields Propose your Plugin Share with the community Conclusion Introduction In the previous post article we covered all the basics to develop a plugin. In this article, we'll focus on the steps to register and allow the community to use it.\nThe registration is mandatory for source plugins and optional (but still recommend) for extractor plugins. This blog will talk about the registration of source plugins.\nThe registry At the moment, what we call the Plugin Registry is a git repository that centralizes all available plugins through a yaml file.\nThe table in the README is auto generated by aforementioned registry:\nID Name Event Source Description Info 2 cloudtrail aws_cloudtrail Reads Cloudtrail JSON logs from files/S3 and injects as events Authors: The Falco Authors License: Apache-2.0 3 dummy dummy Reference plugin used to document interface Authors: The Falco Authors License: Apache-2.0 4 dummy_c dummy_c Like Dummy, but written in C++ Authors: The Falco Authors License: Apache-2.0 999 test test This ID is reserved for source plugin development. Any plugin author can use this ID, but authors can expect events from other developers with this ID. After development is complete, the author should request an actual ID Authors: N/A License: N/A Details of your plugin In this section, we'll describe the key elements to get your plugin allowed to register.\nThe registration needs you to create a nice README for your plugin, but also complete all fields for plugins section of registry.yaml, like:\nplugins: source: - id: 2 source: aws_cloudtrail name: cloudtrail description: Reads Cloudtrail JSON logs from files/S3 and injects as events authors: The Falco Authors contact: https://falco.org/community url: https://github.com/falcosecurity/plugins/tree/master/plugins/cloudtrail license: Apache-2.0 License You're free to choose the open source license you want, you can check https://choosealicense.com/ for help. Most of current plugins are under Apache License 2.0.\nID Every source plugin requires its own unique plugin event ID to interoperate with Falco and the other plugins. This ID is used in the following ways:\nIt is stored inside in-memory event objects and used to identify the associated plugin that injected the event. It is stored in capture files and used to recreate in-memory event objects when reading capture files. It must be unique to ensure that events written by a given plugin will be properly associated with that plugin (and its event sources, see below).\nName Each plugin in the registry must have its own name and can be different from event source, that can be shared across different plugins (eg, for k8s audit logs, we may have different plugins but only one type of event source).\nThe name should match this regular expression ^[a-z]+[a-z0-9_]*$.\nFields The fields are used for conditions in rules, you must describe the available fields of your plugin in the README.\nFor example:\nName Type Description docker.status string Status of the event docker.id string ID of the event docker.from string From of the event (deprecated) docker.type string Type of the event docker.action string Action of the event docker.stack.namespace string Stack Namespace Propose your Plugin Once you're ready, you can submit your plugin to registration:\nfork https://github.com/falcosecurity/plugins update falcosecurity/plugins/edit/master/registry.yaml for adding your plugin in the plugins section submit your PR to falcosecurity/plugins Following our Contributing Guide your commits must be signed-off.\nYou can find more information here.\nShare with the community By sharing your idea and code with the community, you will have direct feedbacks. Don't hesitate to share your work in the Slack kubernetes#falco before submitting your PR too!\nConclusion You should now be able to propose your plugin to the community and have feedbacks about it. The following posts will describe more advanced use-cases like events from Cloud Services. Stay tuned!\nYou can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or even for a friendly chat!\nIf you would like to find out more about Falco:\nGet started in Falco.org Plugin Documentation Plugin Developer Guide Plugin registry Check out the Falco project in GitHub Get involved in the Falco community Meet the maintainers on the Falco Slack Follow @falco_org on Twitter ","summary":"","tags":null,"title":"Extend Falco inputs by creating a Plugin: Register the plugin","url":"https://v0-43--falcosecurity.netlify.app/blog/extend-falco-inputs-with-a-plugin-register/"},{"category":"blog","content":" This post is is part of a series of articles about How to develop Falco plugins. It's adressed to anybody who would like to understand how plugins are written and want to contribute. See other articles:\nExtend Falco inputs by creating a Plugin: Register the plugin Extend Falco inputs by creating a Plugin: Distribute the plugin 2022/07/08 - Updates to reflect last features of the Go SDK\nWhat are Plugins? Developers Guide The plugin Go SDK Requirements Code Organization The plugin codebase plugin/main.go The imports The const The functions main() init() pkg/docker.go The imports The global variables The structures The functions and methods SetInfo() Info() Init() InitSchema() Fields() String() Extract() Open() The repository Build Installation Configuration Rules Test and Results Sources To Go further Conclusion What are Plugins? Before starting, you should take a look at these posts to know more about what Plugins are, what they can do and what concepts are behind them:\nFalco Plugins Early Access Falco 0.31.0 a.k.a. \u0026quot;the Gyrfalcon\u0026quot; Announcing Plugins and Cloud Security with Falco Developers Guide This post has not for purpose to replace the official documentation, it's a step-by-step example to get you to know minimal requirements for having a running plugin. For details, please read the developers guide.\nThe plugin For this example, we'll create a plugin for docker events from a local docker daemon. It is a basic example of an event stream with a basic format and without specific authentication.\nSee an example of events we'll be able to gather and apply Falco rules over:\n2022-02-08T10:58:56.370816183+01:00 container create e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6 (image=alpine, name=confident_kirch) 2022-02-08T10:58:56.371818906+01:00 container attach e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6 (image=alpine, name=confident_kirch) 2022-02-08T10:58:56.482094215+01:00 network connect 5864a44bccca4e0963dfe9c3087919bf8f8e5c3aa7db33dd6d9ae7138c5ee3f3 (container=e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6, name=bridge, type=bridge) 2022-02-08T10:58:56.804166856+01:00 container start e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6 (image=alpine, name=confident_kirch) 2022-02-08T10:58:56.831912702+01:00 container die e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6 (exitCode=0, image=alpine, name=confident_kirch) 2022-02-08T10:58:57.072125878+01:00 network disconnect 5864a44bccca4e0963dfe9c3087919bf8f8e5c3aa7db33dd6d9ae7138c5ee3f3 (container=e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6, name=bridge, type=bridge) 2022-02-08T10:58:57.132390363+01:00 container destroy e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6 (image=alpine, name=confident_kirch) Go SDK For reducing the complixity to communicate with the docker daemon, we'll use the official docker sdk.\nRequirements For this post and following ones, we'll develop in Go, because it's the most common language for that purpose, a lot of member of the Falco Community and tools for Falco are already using it. We'll also use the Go Plugin SDK the maintainers provide for enhancing the experience with plugins.\nThe only requirements for this examples are:\na docker daemon running in your local system falco 0.32 installed in your local system go \u0026gt;= 1.17 Code Organization To simplify contributions and keep a consistency between plugins, we propose a specific organization for the repositories of plugins:\n. ├── LICENSE ├── Makefile ├── README.md ├── falco.yaml ├── go.mod ├── go.sum ├── pkg │ └── docker.go ├── plugin │ └── main.go └── rules └── docker_rules.yaml The directories:\npkg: contains all modules for our plugin, we use a pkg folder because they might be imported and used by other plugins plugin: contains the main.go of our plugin rules: contains one or more .yaml files with default rules for the plugin The files:\nLICENSE: the license file, most of the plugins are under Apache License 2.0 README: the README, see in the repository for an example Makefile: allows to easily build and install the plugin, see in the repository for an example falco.yaml: (optionnal) an example file with the minimal configuration to use the plugin go.mod, go.sum: classic go module files The plugin codebase plugin/main.go This is the entrypoint of our plugin.\npackage main import ( docker \u0026#34;github.com/Issif/docker-plugin/pkg\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/extractor\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/source\u0026#34; ) const ( PluginID uint32 = 5 PluginName = \u0026#34;docker\u0026#34; PluginDescription = \u0026#34;Docker Events\u0026#34; PluginContact = \u0026#34;github.com/falcosecurity/plugins/\u0026#34; PluginVersion = \u0026#34;0.2.0\u0026#34; PluginEventSource = \u0026#34;docker\u0026#34; ) func init() { plugins.SetFactory(func() plugins.Plugin { p := \u0026amp;docker.Plugin{} p.SetInfo( PluginID, PluginName, PluginDescription, PluginContact, PluginVersion, PluginEventSource, ) extractor.Register(p) source.Register(p) return p }) } func main() {} The imports Despite basic Go modules, we'll have to import the different plugin-sdk-go modules (\u0026gt;= 0.5.0) and other modules we need for our plugin:\nimport ( docker \u0026#34;github.com/Issif/docker-plugin/pkg\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/extractor\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/source\u0026#34; ) We'll import these different components of plugin-sdk-go in almost every plugin we'll write. They're really convenient and provide a much easier way to deal with the Falco plugin framework.\nThe const const ( ID uint32 = 5 Name = \u0026#34;docker\u0026#34; Description = \u0026#34;Docker Events\u0026#34; Contact = \u0026#34;github.com/Issif/docker-plugin\u0026#34; Version = \u0026#34;0.2.0\u0026#34; EventSource = \u0026#34;docker\u0026#34; ) The const are used to declare all mandatory informations of our plugin through the docker.SetInfo() method:\nID: must be unique among all plugins, it's used by the framework in captures to know which plugin is the source of events. It's also important for avoiding collisions if you want to share your plugin in the registry, see the main repository for more details Name: the name of our plugin, will be used in plugins section of falco.yaml Description: the description of our plugin Contact: a contact link, often a link to the repository Version: all plugins must be versionned for compatibility with Falco EventSource: this represents the value we'll set in Falco rules for mapping, in our case, all rules we'll set will have source: docker The functions main() The main() function is mandatory for any go program, but because we'll build the plugin as a library for the Falco plugin framework which is written in C, we can let it empty.\n// main is mandatory but empty, because the plugin will be used as C library by Falco plugin framework func main() {} init() The init() function is used for registering our plugin to the Falco plugin framework, as a source and an extractor. We also use it to set the info of the plugin:\nfunc init() { plugins.SetFactory(func() plugins.Plugin { p := \u0026amp;docker.Plugin{} p.SetInfo( ID, Name, Description, Contact, Version, EventSource, ) extractor.Register(p) source.Register(p) return p }) } The init() contains also some specific functions and methods:\nplugins.SetFactory() is a method to register our plugin to the framework SetInfo() is a method to set the details of our plugin before it's registered to the Falco plugin framework source.Register() allows to declare our plugin as a source to the framework, ie, a plugin to collect events from a source extractor.Register() allows to declare our plugin as an extractor to the framework, ie, a plugin to extract fields from an event pkg/docker.go The module used by our main.go, it can also be imported by other plugins, expecially when it's an extractor.\npackage docker import ( \u0026#34;context\u0026#34; \u0026#34;encoding/json\u0026#34; \u0026#34;fmt\u0026#34; \u0026#34;io\u0026#34; \u0026#34;io/ioutil\u0026#34; \u0026#34;github.com/alecthomas/jsonschema\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/source\u0026#34; dockerTypes \u0026#34;github.com/docker/docker/api/types\u0026#34; dockerEvents \u0026#34;github.com/docker/docker/api/types/events\u0026#34; docker \u0026#34;github.com/moby/docker/client\u0026#34; ) var ( ID uint32 Name string Description string Contact string Version string EventSource string ) type PluginConfig struct { FlushInterval uint64 `json:\u0026#34;flushInterval\u0026#34; jsonschema:\u0026#34;description=Flush Interval in ms (Default: 30)\u0026#34;` } // Plugin represents our plugin type Plugin struct { plugins.BasePlugin Config PluginConfig lastDockerEventMessage dockerEvents.Message lastDockerEventNum uint64 } // setDefault is used to set default values before mapping with InitSchema() func (p *PluginConfig) setDefault() { p.FlushInterval = 30 } // SetInfo is used to set the Info of the plugin func (p *Plugin) SetInfo(id uint32, name, description, contact, version, eventSource string) { ID = id Name = name Contact = contact Version = version EventSource = eventSource } // Info displays information of the plugin to Falco plugin framework func (p *Plugin) Info() *plugins.Info { return \u0026amp;plugins.Info{ ID: ID, Name: Name, Description: Description, Contact: Contact, Version: Version, EventSource: EventSource, } } // InitSchema map the configuration values with Plugin structure through JSONSchema tags func (p *Plugin) InitSchema() *sdk.SchemaInfo { reflector := jsonschema.Reflector{ RequiredFromJSONSchemaTags: true, // all properties are optional by default AllowAdditionalProperties: true, // unrecognized properties don\u0026#39;t cause a parsing failures } if schema, err := reflector.Reflect(\u0026amp;PluginConfig{}).MarshalJSON(); err == nil { return \u0026amp;sdk.SchemaInfo{ Schema: string(schema), } } return nil } // Init is called by the Falco plugin framework as first entry, // we use it for setting default configuration values and mapping // values from `init_config` (json format for this plugin) func (p *Plugin) Init(config string) error { p.Config.setDefault() return json.Unmarshal([]byte(config), \u0026amp;p.Config) } // Fields exposes to Falco plugin framework all availables fields for this plugin func (p *Plugin) Fields() []sdk.FieldEntry { return []sdk.FieldEntry{ {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.status\u0026#34;, Display: \u0026#34;Status\u0026#34;, Desc: \u0026#34;Status of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.id\u0026#34;, Display: \u0026#34;ID\u0026#34;, Desc: \u0026#34;ID of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.from\u0026#34;, Display: \u0026#34;From\u0026#34;, Desc: \u0026#34;From of the event (deprecated)\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.type\u0026#34;, Display: \u0026#34;Type\u0026#34;, Desc: \u0026#34;Type of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.action\u0026#34;, Display: \u0026#34;Action\u0026#34;, Desc: \u0026#34;Action of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.stack.namespace\u0026#34;, Display: \u0026#34;Stack Namespace\u0026#34;, Desc: \u0026#34;Stack Namespace\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.id\u0026#34;, Display: \u0026#34;Node ID\u0026#34;, Desc: \u0026#34;Swarm Node ID\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.task\u0026#34;, Display: \u0026#34;Task\u0026#34;, Desc: \u0026#34;Swarm Task\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.taskid\u0026#34;, Display: \u0026#34;Task ID\u0026#34;, Desc: \u0026#34;Swarm Task ID\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.taskname\u0026#34;, Display: \u0026#34;Task Name\u0026#34;, Desc: \u0026#34;Swarm Task Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.servicename\u0026#34;, Display: \u0026#34;Service Name\u0026#34;, Desc: \u0026#34;Swarm Service Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.statenew\u0026#34;, Display: \u0026#34;New State\u0026#34;, Desc: \u0026#34;Node New State\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.stateold\u0026#34;, Display: \u0026#34;Old State\u0026#34;, Desc: \u0026#34;Node Old State\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.container\u0026#34;, Display: \u0026#34;Container\u0026#34;, Desc: \u0026#34;Attribute Container\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.image\u0026#34;, Display: \u0026#34;Image\u0026#34;, Desc: \u0026#34;Attribute Image\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.name\u0026#34;, Display: \u0026#34;Name\u0026#34;, Desc: \u0026#34;Attribute Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.type\u0026#34;, Display: \u0026#34;Type\u0026#34;, Desc: \u0026#34;Attribute Type\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.exitcode\u0026#34;, Display: \u0026#34;Exit Code\u0026#34;, Desc: \u0026#34;Attribute Exit Code\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.signal\u0026#34;, Display: \u0026#34;Signal\u0026#34;, Desc: \u0026#34;Attribute Signal\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.scope\u0026#34;, Display: \u0026#34;Scope\u0026#34;, Desc: \u0026#34;Scope\u0026#34;}, } } // Extract allows Falco plugin framework to get values for all available fields func (p *Plugin) Extract(req sdk.ExtractRequest, evt sdk.EventReader) error { msg := p.lastDockerEventMessage // For avoiding to Unmarshal the same message for each field to extract // we store it with its EventNum. When it\u0026#39;s a new event with a new message, we // update the Plugin struct. if evt.EventNum() != p.lastDockerEventNum { rawData, err := ioutil.ReadAll(evt.Reader()) if err != nil { fmt.Println(err.Error()) return err } err = json.Unmarshal(rawData, \u0026amp;msg) if err != nil { return err } p.lastDockerEventMessage = msg p.lastDockerEventNum = evt.EventNum() } switch req.Field() { case \u0026#34;docker.status\u0026#34;: req.SetValue(msg.Status) case \u0026#34;docker.id\u0026#34;: req.SetValue(msg.ID) case \u0026#34;docker.from\u0026#34;: req.SetValue(msg.From) case \u0026#34;docker.type\u0026#34;: req.SetValue(msg.Type) case \u0026#34;docker.action\u0026#34;: req.SetValue(msg.Action) case \u0026#34;docker.scope\u0026#34;: req.SetValue(msg.Scope) case \u0026#34;docker.actor.id\u0026#34;: req.SetValue(msg.Actor.ID) case \u0026#34;docker.stack.namespace\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.stack.namespace\u0026#34;]) case \u0026#34;docker.swarm.task\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task\u0026#34;]) case \u0026#34;docker.swarm.taskid\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task.id\u0026#34;]) case \u0026#34;docker.swarm.taskname\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task.name\u0026#34;]) case \u0026#34;docker.swarm.servicename\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.service.name\u0026#34;]) case \u0026#34;docker.node.id\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.node.id\u0026#34;]) case \u0026#34;docker.node.statenew\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;state.new\u0026#34;]) case \u0026#34;docker.node.stateold\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;state.old\u0026#34;]) case \u0026#34;docker.attributes.container\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;container\u0026#34;]) case \u0026#34;docker.attributes.image\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;image\u0026#34;]) case \u0026#34;docker.attributes.name\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;name\u0026#34;]) case \u0026#34;docker.attributes.type\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;type\u0026#34;]) default: return fmt.Errorf(\u0026#34;no known field: %s\u0026#34;, req.Field()) } return nil } // Open is called by Falco plugin framework for opening a stream of events, we call that an instance func (Plugin *Plugin) Open(params string) (source.Instance, error) { dclient, err := docker.NewClientWithOpts() if err != nil { return nil, err } eventC := make(chan source.PushEvent) ctx, cancel := context.WithCancel(context.Background()) // launch an async worker that listens for Docker events and pushes them // to the event channel go func() { defer close(eventC) msgC, errC := dclient.Events(ctx, dockerTypes.EventsOptions{}) var msg dockerEvents.Message var err error for { select { case msg = \u0026lt;-msgC: bytes, err := json.Marshal(msg) if err != nil { eventC \u0026lt;- source.PushEvent{Err: err} // errors are blocking, so we can stop here return } eventC \u0026lt;- source.PushEvent{Data: bytes} case err = \u0026lt;-errC: if err == io.EOF { // map EOF to sdk.ErrEOF, which is recognized by the Go SDK err = sdk.ErrEOF } eventC \u0026lt;- source.PushEvent{Err: err} // errors are blocking, so we can stop here return } } }() return source.NewPushInstance(eventC, source.WithInstanceClose(cancel)) } // String represents the raw value of on event // (not currently used by Falco plugin framework, only there for future usage) func (Plugin *Plugin) String(in io.ReadSeeker) (string, error) { evtBytes, err := ioutil.ReadAll(in) if err != nil { return \u0026#34;\u0026#34;, err } evtStr := string(evtBytes) return fmt.Sprintf(\u0026#34;%v\u0026#34;, evtStr), nil } The imports Despite basic Go modules, we'll have to import the different modules from plugin-sdk-go and from Docker SDK to docker events:\nimport ( \u0026#34;context\u0026#34; \u0026#34;encoding/json\u0026#34; \u0026#34;fmt\u0026#34; \u0026#34;io\u0026#34; \u0026#34;io/ioutil\u0026#34; \u0026#34;github.com/alecthomas/jsonschema\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/source\u0026#34; dockerTypes \u0026#34;github.com/docker/docker/api/types\u0026#34; dockerEvents \u0026#34;github.com/docker/docker/api/types/events\u0026#34; docker \u0026#34;github.com/moby/docker/client\u0026#34; ) The global variables Global variables are declared and filled with the SetInfo() method called by the init() of the main.go. These variables are then used to declare the details of the plugin to Falco:\nvar ( ID uint32 Name string Description string Contact string Version string EventSource string ) The structures The structure to declare the plugin is mandatory and must respect the interface declared in the SDK:\ntype PluginConfig struct { FlushInterval uint64 `json:\u0026#34;flushInterval\u0026#34; jsonschema:\u0026#34;description=Flush Interval in ms (Default: 30)\u0026#34;` } // Plugin represents our plugin type Plugin struct { plugins.BasePlugin Config PluginConfig lastDockerEventMessage dockerEvents.Message lastDockerEventNum uint64 } Plugin represents our plugin that will be loaded by the framework. It contains some fields:\nplugins.BasePlugin: allows to respect the Plugin interface of the SDK Config: contains the configuration of our plugin, represented by the PluginConfig structure lastDockerEventMessage: contains the result of the last unmarshalled event lastDockerEventNum: contains the number of the unmarshalled event, by comparing it, we avoid to unmarshal the same event several times PluginConfig represents the configuration of our plugin, we'll use the module alecthomas/jsonschema to map the content of init_config from the plugin section of falco.yaml and check its validity:\nplugins: - name: docker library_path: /etc/falco/audit/libdocker.so init_config: \u0026#39;{\u0026#34;flushinterval\u0026#34;: 10}\u0026#39; open_params: \u0026#39;\u0026#39; The functions and methods SetInfo() It's used to set the global variables which represent the details of our plugin, this method is called by the init() of the main.go:\n// SetInfo is used to set the Info of the plugin func (p *Plugin) SetInfo(id uint32, name, description, contact, version, eventSource string) { ID = id Name = name Contact = contact Version = version EventSource = eventSource } Info() This method is mandatory and all plugins must respect that. It allows the Falco plugin framework to have all intels about the plugin itself, we use the global variables and the SetInfo() method to set the values:\n// Info displays information of the plugin to Falco plugin framework func (p *Plugin) Info() *plugins.Info { return \u0026amp;plugins.Info{ ID: ID, Name: Name, Description: Description, Contact: Contact, Version: Version, EventSource: EventSource, } } Init() This method (:warning: different from the function init()) will be the first one called by the Falco plugin framework, we use setDefault() to set the default values of the config. In our case, these default values are overridden by the values from init_config:.\n// Init is called by the Falco plugin framework as first entry, // we use it for setting default configuration values and mapping // values from `init_config` (json format for this plugin) func (p *Plugin) Init(config string) error { p.Config.setDefault() return json.Unmarshal([]byte(config), \u0026amp;p.Config) } InitSchema() InitSchema() and the jsonschema tags from the fields of PluginConfig struct are used to check the validity of the content of init_config from falco.yaml.\n// InitSchema map the configuration values with Plugin structure through JSONSchema tags func (p *Plugin) InitSchema() *sdk.SchemaInfo { reflector := jsonschema.Reflector{ RequiredFromJSONSchemaTags: true, // all properties are optional by default AllowAdditionalProperties: true, // unrecognized properties don\u0026#39;t cause a parsing failures } if schema, err := reflector.Reflect(\u0026amp;PluginConfig{}).MarshalJSON(); err == nil { return \u0026amp;sdk.SchemaInfo{ Schema: string(schema), } } return nil } It uses a json schema reflector, see jsonschema for more details about how it works.\nFields() This method declares to the Falco plugin framework all fields that will be available for the rules, with their names and their types.\n// Fields exposes to Falco plugin framework all availables fields for this plugin func (dockerPlugin *DockerPlugin) Fields() []sdk.FieldEntry { return []sdk.FieldEntry{ {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.status\u0026#34;, Display: \u0026#34;Status\u0026#34;, Desc: \u0026#34;Status of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.id\u0026#34;, Display: \u0026#34;ID\u0026#34;, Desc: \u0026#34;ID of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.from\u0026#34;, Display: \u0026#34;From\u0026#34;, Desc: \u0026#34;From of the event (deprecated)\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.type\u0026#34;, Display: \u0026#34;Type\u0026#34;, Desc: \u0026#34;Type of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.action\u0026#34;, Display: \u0026#34;Action\u0026#34;, Desc: \u0026#34;Action of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.stack.namespace\u0026#34;, Display: \u0026#34;Stack Namespace\u0026#34;, Desc: \u0026#34;Stack Namespace\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.id\u0026#34;, Display: \u0026#34;Node ID\u0026#34;, Desc: \u0026#34;Swarm Node ID\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.task\u0026#34;, Display: \u0026#34;Task\u0026#34;, Desc: \u0026#34;Swarm Task\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.taskid\u0026#34;, Display: \u0026#34;Task ID\u0026#34;, Desc: \u0026#34;Swarm Task ID\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.taskname\u0026#34;, Display: \u0026#34;Task Name\u0026#34;, Desc: \u0026#34;Swarm Task Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.servicename\u0026#34;, Display: \u0026#34;Service Name\u0026#34;, Desc: \u0026#34;Swarm Service Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.statenew\u0026#34;, Display: \u0026#34;New State\u0026#34;, Desc: \u0026#34;Node New State\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.stateold\u0026#34;, Display: \u0026#34;Old State\u0026#34;, Desc: \u0026#34;Node Old State\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.container\u0026#34;, Display: \u0026#34;Container\u0026#34;, Desc: \u0026#34;Attribute Container\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.image\u0026#34;, Display: \u0026#34;Image\u0026#34;, Desc: \u0026#34;Attribute Image\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.name\u0026#34;, Display: \u0026#34;Name\u0026#34;, Desc: \u0026#34;Attribute Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.type\u0026#34;, Display: \u0026#34;Type\u0026#34;, Desc: \u0026#34;Attribute Type\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.exitcode\u0026#34;, Display: \u0026#34;Exit Code\u0026#34;, Desc: \u0026#34;Attribute Exit Code\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.signal\u0026#34;, Display: \u0026#34;Signal\u0026#34;, Desc: \u0026#34;Attribute Signal\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.scope\u0026#34;, Display: \u0026#34;Scope\u0026#34;, Desc: \u0026#34;Scope\u0026#34;}, } } String() Even if this method is mandatory, it's not used by Falco for now but must be set up for future usage. It simply retrieves the events, it can be in JSON or any format as long it contains the whole content of the source event.\n// String represents the raw value of on event // (not currently used by Falco plugin framework, only there for future usage) func (dockerPlugin *DockerPlugin) String(in io.ReadSeeker) (string, error) { evtBytes, err := ioutil.ReadAll(in) if err != nil { return \u0026#34;\u0026#34;, err } evtStr := string(evtBytes) return fmt.Sprintf(\u0026#34;%v\u0026#34;, evtStr), nil } Extract() This method is called by the Falco plugin framework for getting the values of fields:\n// Extract allows Falco plugin framework to get values for all available fields func (p *Plugin) Extract(req sdk.ExtractRequest, evt sdk.EventReader) error { msg := p.lastDockerEventMessage // For avoiding to Unmarshal the same message for each field to extract // we store it with its EventNum. When it\u0026#39;s a new event with a new message, we // update the Plugin struct. if evt.EventNum() != p.lastDockerEventNum { rawData, err := ioutil.ReadAll(evt.Reader()) if err != nil { fmt.Println(err.Error()) return err } err = json.Unmarshal(rawData, \u0026amp;msg) if err != nil { return err } p.lastDockerEventMessage = msg p.lastDockerEventNum = evt.EventNum() } switch req.Field() { case \u0026#34;docker.status\u0026#34;: req.SetValue(msg.Status) case \u0026#34;docker.id\u0026#34;: req.SetValue(msg.ID) case \u0026#34;docker.from\u0026#34;: req.SetValue(msg.From) case \u0026#34;docker.type\u0026#34;: req.SetValue(msg.Type) case \u0026#34;docker.action\u0026#34;: req.SetValue(msg.Action) case \u0026#34;docker.scope\u0026#34;: req.SetValue(msg.Scope) case \u0026#34;docker.actor.id\u0026#34;: req.SetValue(msg.Actor.ID) case \u0026#34;docker.stack.namespace\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.stack.namespace\u0026#34;]) case \u0026#34;docker.swarm.task\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task\u0026#34;]) case \u0026#34;docker.swarm.taskid\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task.id\u0026#34;]) case \u0026#34;docker.swarm.taskname\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task.name\u0026#34;]) case \u0026#34;docker.swarm.servicename\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.service.name\u0026#34;]) case \u0026#34;docker.node.id\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.node.id\u0026#34;]) case \u0026#34;docker.node.statenew\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;state.new\u0026#34;]) case \u0026#34;docker.node.stateold\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;state.old\u0026#34;]) case \u0026#34;docker.attributes.container\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;container\u0026#34;]) case \u0026#34;docker.attributes.image\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;image\u0026#34;]) case \u0026#34;docker.attributes.name\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;name\u0026#34;]) case \u0026#34;docker.attributes.type\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;type\u0026#34;]) default: return fmt.Errorf(\u0026#34;no known field: %s\u0026#34;, req.Field()) } return nil } :warning: try to not overlap the fields created by other plugins, for eg, in this example we can use docker. prefix because Falco libs use container. fields which are more generic, so we've not a conflict.\nFor this plugin, we use the modules provided by the Docker SDK, all retrieved events will be unmarshaled into the events.Message struct which simplifies the mapping and the extraction of fields.\nTo avoid to unmarshall for each field extraction the same message and impact the performances, we store the number (=~ID) and the result of the last unmarshalled message. When the number change, it means it's not the same event and we can unmarshall its message and store it with its number.\nmsg := p.lastDockerEventMessage // For avoiding to Unmarshal the same message for each field to extract // we store it with its EventNum. When it\u0026#39;s a new event with a new message, we // update the Plugin struct. if evt.EventNum() != p.lastDockerEventNum { rawData, err := ioutil.ReadAll(evt.Reader()) if err != nil { fmt.Println(err.Error()) return err } err = json.Unmarshal(rawData, \u0026amp;msg) if err != nil { return err } p.lastDockerEventMessage = msg p.lastDockerEventNum = evt.EventNum() } Open() This methods is used by the Falco plugin framework for opening a new stream of events, what is called an instance (source.Instance). The current implementation creates only one instance per plugin but it's possible in future that same plugin allows to open several streams, and so several instances at once.\nTo simplify the creation of this source.Instance, the Go SDK provides two easy functions, see the docs:\nsource.NewPullInstance: for when the event source can be implemented sequentially and the time required to generate a sequence of event is deterministic, eg: periodic calls to an external API souce.NewPushInstance: for when the event source can be suspensive and there is no time guarantee reguarding when an event gets produced, eg: we wait a webhook from an external service For collecting events from docker, we'll use souce.NewPushInstance as the docker SDK creates a channel and sends the events into when they happened.\n// Open is called by Falco plugin framework for opening a stream of events, we call that an instance func (Plugin *Plugin) Open(params string) (source.Instance, error) { dclient, err := docker.NewClientWithOpts() if err != nil { return nil, err } eventC := make(chan source.PushEvent) ctx, cancel := context.WithCancel(context.Background()) // launch an async worker that listens for Docker events and pushes them // to the event channel go func() { defer close(eventC) msgC, errC := dclient.Events(ctx, dockerTypes.EventsOptions{}) var msg dockerEvents.Message var err error for { select { case msg = \u0026lt;-msgC: bytes, err := json.Marshal(msg) if err != nil { eventC \u0026lt;- source.PushEvent{Err: err} // errors are blocking, so we can stop here return } eventC \u0026lt;- source.PushEvent{Data: bytes} case err = \u0026lt;-errC: if err == io.EOF { // map EOF to sdk.ErrEOF, which is recognized by the Go SDK err = sdk.ErrEOF } eventC \u0026lt;- source.PushEvent{Err: err} // errors are blocking, so we can stop here return } } }() return source.NewPushInstance(eventC, source.WithInstanceClose(cancel)) } We'll not describe with details the docker relative part, see the documentation of the Docker SDK for more info. You just have to know it creates a channel to receive the events from the engine and we use same context than the whole plugin.\nHere's the most important things to notice:\neventC := make(chan source.PushEvent): we create a channel, it will be used by the instance to listen incoming events, we'll push into it the events from the docker client ctx, cancel := context.WithCancel(context.Background()): we create a context, and more important, a Done channel for this context eventC \u0026lt;- source.PushEvent{Data: bytes}: this is how to push an event to the instance return source.NewPushInstance(eventC, source.WithInstanceClose(cancel)): the Open() method must return a source.Instance, and source.NewPushInstance() requires a channel where the events will pushed and may have optionnal settings, in our case, we pass also the Done channel of the context with the source.WithInstanceClose() function Passing to the instance the same Done channel than the docker client uses, allows to correctly stop the plugin when we ask Falco to stop (CTRL+C or systemctl stop falco).\nThe repository You can find the complete plugin with all details in its repository. Feel free to create issues or PR.\nBuild The plugin is built as a c-shared library, it means a .so:\ngo build -buildmode=c-shared -o libdocker.so If you use make from the repository:\nmake build Installation The plugins are commonly installed in /usr/share/falco/plugins, just move the libdocker.so you built or run make install.\nConfiguration Now we have our plugin, we must declare it to Falco in falco.yaml:\nplugins: - name: docker library_path: /usr/share/falco/plugins/libdocker.so init_config: \u0026#39;{\u0026#34;flushinterval\u0026#34;: 1}\u0026#39; load_plugins: [docker] stdout_output: enabled: true For more details about this configuration, the documentation is here.\nRules We create a simple rule, for checking that the fields and source work as expected:\n- rule: Container status changed desc: Container status changed condition: docker.status in (create,start,die) output: status=%docker.status from=%docker.from type=%docker.type action=%docker.action name=%docker.attributes.name priority: DEBUG source: docker tags: [docker] Test and Results Let's run Falco with our configuration and rules files:\nfalco -c falco.yaml -r docker_rules.yaml 17:17:24.008405000: Debug status=create from=alpine type=container action=create name=bold_keller 17:17:24.008953000: Debug status=start from=alpine type=container action=start name=bold_keller 17:17:24.009076000: Debug status=die from=alpine type=container action=die name=bold_keller Events detected: 3 Rule counts by severity: DEBUG: 3 Triggered rules by rule name: Container status changed: 3 Syscall event drop monitoring: - event drop detected: 0 occurrences - num times actions taken: 0 :tada: It works!\nSources All files of this post can be found on this repo.\nTo Go further Once your plugin is done, you can share it with the community, by registrating it. The next post Extend Falco inputs by creating a Plugin: Register the plugin will guide you through the process.\nConclusion With this first post, you should have now all basics for creating your own plugin. The following posts will describe more advanced use-cases like collecting events from Cloud Services. Stay tuned :wink:.\nYou can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or even for a friendly chat!\nIf you would like to find out more about Falco:\nGet started in Falco.org Plugin Documentation Plugin Developer Guide Plugin registry Check out the Falco project in GitHub Get involved in the Falco community Meet the maintainers on the Falco Slack Follow @falco_org on Twitter ","summary":"","tags":null,"title":"Extend Falco inputs by creating a Plugin: the basics","url":"https://v0-43--falcosecurity.netlify.app/blog/extend-falco-inputs-with-a-plugin-the-basics/"},{"category":"blog","content":"The just released Falco v0.31.0 is the result of several months of hard work and includes many exciting new features. One of them, however, is particularly strategic for Falco as a project: the general availability of the plugins framework. I would like to use this blog post to explain why plugins are exciting and what they mean for the future of Falco. Let’s start by explaining what this new technology is.\nWhat Are Plugins? Plugins are shared libraries that can be loaded by Falco to extend its functionality. Plugins come in two flavors:\nSource Plugins add new data sources to Falco. They produce input events, from either the local machine or a remote source, that Falco can understand. Extractor Plugins parse the data coming from source plugins and expose new fields that can be used in Falco rules. The combination of Source and Extractor plugins allows users to feed arbitrary data into Falco, parse it in useful ways and create rules and policies from it. Let me give you an example: the Cloudtrail plugin extends Falco to understand Cloudtrail logs (either local or stored on S3) and allows you to write rules like this one:\n- rule: Console Login Without MFA desc: Detect a console login without MFA. condition: ct.name=\u0026#34;ConsoleLogin\u0026#34; and ct.error=\u0026#34;\u0026#34; and ct.user.identitytype!=\u0026#34;AssumedRole\u0026#34; and json.value[/responseElements/ConsoleLogin]=\u0026#34;Success\u0026#34; and json.value[/additionalEventData/MFAUsed]=\u0026#34;No\u0026#34; output: Detected a console login without MFA (requesting user=%ct.user, requesting IP=%ct.srcip, AWS region=%ct.region) priority: CRITICAL source: aws_cloudtrail A rule like the one above is validated and evaluated by your out-of-the-box Falco. But with plugins, rules can now be applied to almost any data source where you can write a plugin for it. And you can add new data sources without even having to rebuild Falco.\nWhy Plugins? Falco’s “runtime security” philosophy is based on some key concepts:\nParse data in a streaming fashion to detect threats in real time Implement detection on top of an engine that is lightweight to run and easy to deploy Offer a compact rule language that is quick to learn but flexible and expressive This philosophy has proved to be very effective with system calls, and is the reason why Falco has thrived as a runtime security solution for containers.\nPlugins extend the applicability of this philosophy to an endless number of new domains. One of these domains is cloud security.\nRuntime Security: a Better Option for Threat Detection in the Cloud Cloud security is a fertile and constantly evolving space. When implementing cloud security you can choose among many different options. However, architecturally, most options fall in one of the following categories:\nTools that query the cloud APIs or watch cloud data stores to detect misconfigurations or vulnerabilities Tools that stream cloud logs into a backend, index them and let you query them To detect threats in cloud-based software, Category 1 is not very useful. Polling is great to detect gaps and validate compliance, but lacks the real-time nature required to detect threats and respond quickly. Category 2 is powerful, but it’s also tremendously expensive (especially in environments like the public cloud where tons of logs are produced) and not friendly to deploy and use.\nI argue that the Falco runtime security approach is the ideal one. Falco consumes few resources and, most importantly, it analyzes the data in a streaming way. No need to perform expensive copies, no need to wait until the data is indexed. Falco looks at your data in real-time and notifies you in seconds.\nGetting up and running with Falco takes only a few minutes, and adopting it for both cloud logs and system calls allows a unified approach to threat detection.\nWhat is the future for Falco? V0.31.0 comes with one plugin, Cloudtrail, but expect many more to come in the future. Our vision is to make Falco the runtime policy engine for, well, everything. :-) We want to support all the clouds, and include more services from each of them.\nStay tuned for announcements in the near future, and at the same time, please let us know if there is an area where you would like to see Falco in action in the future. Also, writing your own plugin is easy and, as a community, we would love to consider your creative contribution.\nYou can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or even for a friendly chat!\nIf you would like to find out more about Falco:\nGet started in Falco.org Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":null,"title":"Announcing Plugins and Cloud Security with Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-announcing-plugins/"},{"category":"blog","content":"Today we announce the release of Falco 0.31.0, a.k.a the Gyrfalcon 🦅!\nGyrfalcons 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.\nThe 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.\nPlugin 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.\nFalco 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.\nPlugins 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.\nTo 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!\nOf 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++:\nPlugin SDK Go 👉 https://github.com/falcosecurity/plugin-sdk-go Plugin SDK C++ 👉 https://github.com/falcosecurity/plugin-sdk-cpp 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 ⌚!\nThe 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.\nWe 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.\nDrivers 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.\nThe 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.\nThe 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.\nIssues 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.\nFinally, a lot of effort has been put into upgrading critical dependencies and supporting more architectures and platforms 👉 libs#91, libs#164.\nOther Falco novelties Plugins apart, Falco received a few other significant updates:\nAbility 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 👇\nCreate Hardlink Over Sensitive Files Launch Remote File Copy Tools in Container Existing rules, macros, and lists received some updates too, in particular with regards to possible bypasses 👇\nSudo Potential Privilege Escalation Detect crypto miners using the Stratum protocol spawned_process, sensitive_mount falco_hostnetwork_images, deb_binaries, known_sa_list, falco_sensitive_mount_images 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 🚀 !\nFurthermore, 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.\nSo, stay tuned. The next release may surprise you 😉 !\nLet'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!\nIf you would like to find out more about Falco 👇\nGet involved in the Falco community. Check out the Falco project in GitHub. Meet the maintainers on the Falco Slack. Join the Falco mailing list Follow @falco_org on Twitter. Cheers 🥳 👋 !\nJason \u0026amp; Leonardo\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.31.0 a.k.a. \"the Gyrfalcon\"","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-31-0/"},{"category":"blog","content":"Falco is currently the de facto standard for runtime threat detection in Kubernetes environments. The project is growing at a very fast pace, and so is its open source community. The role of Falco is to collect all the system events of a cluster and send some kind of alert whenever suspicious behavior is detected. Among the other data sources supported, system calls are the core kind of events monitored by Falco.\nUnfortunately, the set of supported syscalls changes from time to time as new versions of the Linux kernel gets released, and Falco needs to be updated accordingly. There are still a bunch of syscalls that are yet not supported by Falco and its libraries. As such, an attacker could potentially compose malicious software that relies on some of these unmonitored syscalls as a means to bypass Falco's security. This is a known issue and has first been reported during this talk by maintainer Leo Di Donato.\nHence, there is a great opportunity in contributing to the project by adding support to some of the missing syscalls. Some of them provide brand new functionalities, whereas others are new alternative versions of already existing syscalls.\nIn this post, we share our experience of implementing the support to openat2, which was still missing from the list. We decided to start by adding this syscall as we thought it could be meaningful for the security monitoring purposes of Falco. We have documented our development process step by step, by sharing our thoughts and by providing some context about the parts involved.\nThe complete source code of this project can be found in the pull request we recently opened.\nThe New Syscall The openat2 syscall is a recently introduced alternative to the already existing openat, created to extend its capabilities and to enhance control and configurability.\n// https://man7.org/linux/man-pages/man2/openat2.2.html long syscall(SYS_openat2, int dirfd, const char *pathname, struct open_how *how, size_t size); The purpose of this syscall is to open a file in a given path or to try creating it if it does not exist. A rich set of flags can control the behavior of this action, and a new data structure open_how has been introduced to be extended in the future in case new configuration flags will be needed. This syscall appeared in the Linux kernel starting from version 5.6, so we can assume it is supported only in the most up-to-date production environments.\nIn theory, the Falco monitoring can potentially be bypassed by using openat2 instead of openat. If malicious software is carefully built to only use openat2, Falco would not be able to detect anomalies related to file opening, thus weakening its security guarantees.\nNonetheless, we found this syscall relatively easy to implement in Falco, because the code that supports openat was already at our disposal.\nArchitectural Overview of Falco Having a high-level understanding of the architecture of Falco is the key to identifying which part of the project needs to be updated while adding a new syscall. On the other hand, we also learned a lot about the Falco codebase while trying to add openat2. The picture below provides an overview of the bottom-up architecture of the project.\nOn the bottom, there are the Kernel Module and the eBPF Probe, which are often simply called drivers. The Kernel Module offers slightly better performance and compatibility, whereas the eBPF probe is optimal in terms of security and modernity.\nThe two drivers are equal in functionality and run in the kernel space to catch internal events (such as syscalls) and then push them up to the userspace. Then, libscap consumes each event and enriches them with some context information. This component can also read and write dump files. The next in line is libsinsp. This is where each event is parsed, inspected, and is evaluated against a set of user-specified filters.\nFinally, Falco and its Rule Engine consume the processed events, orchestrate the behavior of the underlying libraries, and send the output alerts to the outside world. However, the core logic responsible for processing each system call is contained in the low-level drivers (kmod and eBPF) and the userspace libraries.\nAdding OS-Independent Representations The first thing to pay attention to is to make sure that Falco is as independent as possible from specific versions of the Linux kernel or specific platforms. This is attained by creating internal representations and definitions of all the values that are expected to vary across different systems. Most of those definitions are part of the codebase of the drivers, so that's the part that we looked at first.\nEvent and Syscall List First, we noticed the presence of an enumeration representing all the possible system events that are captured at the driver level. This includes syscalls too, among some other event types. We proceeded by adding constants for openat2.\n// driver/ppm_events_public.h enum ppm_event_type { // ... PPME_SYSCALL_OPENAT2_E = 326, PPME_SYSCALL_OPENAT2_X = 327, PPM_EVENT_MAX = 328 }; Most careful readers will notice that we defined two constants for the same syscall. This is mandatory since the Enter and the eXit of a syscall are seen as two distinct events. Most of the time, the interesting one is the exit event because it carries both the syscall arguments and the return value, but there is a value in the enter event for many use cases too.\nThere is also an additional enumeration that defines syscalls specifically. This is the abstract representation of syscalls numbers used internally by the engine.\n// driver/ppm_events_public.h enum ppm_syscall_code { // ... PPM_SC_OPENAT2 = 322, PPM_SC_MAX = 323, }; Last but not least, don't forget to bump PPM_EVENT_MAX and PPM_SC_MAX values too!\nFinally, we noticed that the drivers provide support to the ia32 architecture by maintaining a wide set of definitions. In many cases, some enumerations and definitions are replicated with the _ia32 prefix. At this point, we redefine the actual syscall number of openat2 for ia32.\n// driver/ppm_compat_unistd_32.h // ... #define __NR_ia32_openat2 351 // ... #define NR_ia32_syscalls 352 // ... Again, remember to increment NR_ia32_syscalls value too!\nArgument Flags (optional) In many cases, the syscall arguments include a flag value in which each bit represents a given configuration option. All those options are usually defined as constants, and we need to provide an internal representation for them too. This step is theoretically optional because each syscall varies case by case. In the case of openat2, we re-defined the options of the resolve flag field inside the open_how struct argument.\n// driver/ppm_events_public.h #define PPM_RESOLVE_BENEATH (1 \u0026lt;\u0026lt; 0) #define PPM_RESOLVE_IN_ROOT (1 \u0026lt;\u0026lt; 1) #define PPM_RESOLVE_NO_MAGICLINKS (1 \u0026lt;\u0026lt; 2) #define PPM_RESOLVE_NO_SYMLINKS (1 \u0026lt;\u0026lt; 3) #define PPM_RESOLVE_NO_XDEV (1 \u0026lt;\u0026lt; 4) #define PPM_RESOLVE_CACHED (1 \u0026lt;\u0026lt; 5) // ...\nextern const struct ppm_name_value openat2_flags[]; Accordingly, it's also necessary to create a table containing the textual representations of the flag options. These are usually used for formatting the output alerts of Falco.\n// driver/flags_table.c const struct ppm_name_value openat2_flags[] = { {\u0026#34;RESOLVE_BENEATH\u0026#34;, PPM_RESOLVE_BENEATH}, {\u0026#34;RESOLVE_IN_ROOT\u0026#34;, PPM_RESOLVE_IN_ROOT}, {\u0026#34;RESOLVE_NO_MAGICLINKS\u0026#34;, PPM_RESOLVE_NO_MAGICLINKS}, {\u0026#34;RESOLVE_NO_SYMLINKS\u0026#34;, PPM_RESOLVE_NO_SYMLINKS}, {\u0026#34;RESOLVE_NO_XDEV\u0026#34;, PPM_RESOLVE_NO_XDEV}, {\u0026#34;RESOLVE_CACHED\u0026#34;, PPM_RESOLVE_CACHED}, {0, 0}, }; Quite straightforward so far, uh? Lastly, we needed to create a mapping function that will be invoked by the drivers to convert the flags in the internal representation format:\nstatic __always_inline u32 openat2_resolve_to_scap(unsigned long flags) { u32 res = 0; #ifdef RESOLVE_NO_XDEV if (flags \u0026amp; RESOLVE_NO_XDEV) res |= PPM_RESOLVE_NO_XDEV; #endif // Repeat for all the flags options... return res; } Using ifdefs here is a good practice to avoid compilation issues that may arise on different platforms. Generally, this could be a good practice to make the compilation step as robust as possible, given the fact that openat2 is not yet supported in many kernel versions and standard libraries.\nTables We proceeded in our implementation by modifying the information records that Falco maintains for each event type. These tables are used by both the drivers and libscap, and define a sort of contract describing the event data stream pushed from the kernel.\nStarting from g_event_info, we must fill in the name of the syscall, its category, flags, and all of its arguments. As always, a good rule of thumb is to find a similar syscall already supported to see how it is handled to better understand patterns and good practices. By working on this table, you will surely notice the presence of multiple versions of the same syscall. execve and openat2 are good examples of this phenomenon. The reason is that, in old code revisions, a new version of the same syscall needed to be added every time its signature was changed in the kernel, most probably caused by some new struct fields in any of its parameters.\n// driver/event_table.c const struct ppm_event_info g_event_info[PPM_EVENT_MAX] = { // ... /* PPME_SYSCALL_OPENAT2_E */ { \u0026#34;openat2\u0026#34;, EC_FILE, EF_CREATES_FD | EF_MODIFIES_STATE, 0 }, /* PPME_SYSCALL_OPENAT2_X */ { \u0026#34;openat2\u0026#34;, EC_FILE, EF_CREATES_FD | EF_MODIFIES_STATE, 6, { {\u0026#34;fd\u0026#34;, PT_FD, PF_DEC}, {\u0026#34;dirfd\u0026#34;, PT_FD, PF_DEC}, {\u0026#34;name\u0026#34;, PT_FSRELPATH, PF_NA, DIRFD_PARAM(1)}, {\u0026#34;flags\u0026#34;, PT_FLAGS32, PF_HEX, file_flags}, {\u0026#34;mode\u0026#34;, PT_UINT32, PF_OCT}, {\u0026#34;resolve\u0026#34;, PT_FLAGS32, PF_HEX, openat2_flags} } }, } The next step is to map the events to the fillers, which are the actual tracing code for the syscall that we will cover in the next sections. sys_empty is a simple stub for when we are not interested in having a specific trace, which suits our use case for the syscall enter event.\n// driver/fillers_table.c const struct ppm_event_entry g_ppm_events[PPM_EVENT_MAX] = { // ... [PPME_SYSCALL_OPENAT2_E] = {FILLER_REF(sys_empty)}, [PPME_SYSCALL_OPENAT2_X] = {FILLER_REF(sys_openat2_x)}, } We also need to update FILLER_LIST_MAPPER with the filler for our exit event. This is just a simple X-macro that is used to automatically fill the enum ppm_filler_id and various filler functions declaration in the same header.\n// driver/ppm_fillers.h #define FILLER_LIST_MAPPER(FN) \\ // ... FN(sys_openat2_x) \\ // ... FN(terminate_filler) // ... Next, we will make sure to add the new syscall to both the syscall table and the routing table. g_syscall_table maps a syscall with some flags and its enter and exit events constants. We discovered the meaning of each flag by inspecting its definition and by looking at the way they were used in other parts of the code.\n// driver/syscall_table.c const struct syscall_evt_pair g_syscall_table[SYSCALL_TABLE_SIZE] = { // ... #ifdef __NR_openat2 [__NR_openat2 - SYSCALL_TABLE_ID0] = { UF_USED, PPME_SYSCALL_OPENAT2_E, PPME_SYSCALL_OPENAT2_X }, #endif }; Then, the g_syscall_code_routing_table table maps the platform syscall number to our internal enumeration:\n// driver/syscall_table.c const enum ppm_syscall_code g_syscall_code_routing_table[SYSCALL_TABLE_SIZE] = { // ... #ifdef __NR_openat2 [__NR_openat2 - SYSCALL_TABLE_ID0] = PPM_SC_OPENAT2, #endif }; Be mindful that there are counterparts of g_syscall_code_routing_table and g_syscall_table for ia32. Please be sure of updating those too!\nFillers Ok, we are finally nearing real kernel code! Fillers are functions that implement the specific capturing behavior for each event. There is a filler for each enter and exit event of the supported syscalls, wherever they are not stubbed by sys_empty. Fillers need to be implemented for both the kernel module and the eBPF probe separately.\nThe logic of filler functions is pretty straightforward. All they need to do is collect the return value and the arguments of a syscall, either at the enter or the exit event and then push that information in a ring buffer. Then, libscap takes care of consuming the data in the ring buffer from the userspace. The extraction of those values, and pushing to the ring buffer, is implemented by specific helper methods.\nKernel module To write the kernel module filler function, let's head to driver/ppm_fillers.c where we can find lots of f_sys_ functions. We just need to write a new one using the same name that we previously added to driver/ppm_fillers.h. Our openat2 filler function for the exit event looks as follows:\n// driver/ppm_fillers.c int f_sys_openat2_x(struct event_filler_arguments *args) { // ... return add_sentinel(args); } The first thing to do is setting the return value and pushing it to the ring buffer:\nint64_t retval = (int64_t)syscall_get_return_value(current, args-\u0026gt;regs); int res = val_to_ring(args, retval, 0, false, 0); if (unlikely(res != PPM_SUCCESS)) return res; Then, we collect each argument and push it to the ring buffer. Be mindful that the order with which we push data on the ring buffer needs to be coherent with the one that is expected in the userspace by libscap and libsinsp.\nsyscall_get_arguments_deprecated(current, args-\u0026gt;regs, 1, 1, \u0026amp;val); res = val_to_ring(args, val, 0, true, 0); if (unlikely(res != PPM_SUCCESS)) return res; At this point, we had to decide whether to push the open_how struct argument in the ring right ahead or to flatten it and push all its fields one by one. We had good reasons to opt for the second option. First, due to the novelty of openat2 and its definitions, we wanted to isolate the usage of the data structure only at the kernel level to avoid compilation errors and make the build system more resilient. Second, the data structure may be not defined in userspace even if the kernel sees and compiles it, due to a potential mismatch between the glibc version and the installed kernel headers. Lastly, libscap and the components above are designed to be independent of the underlying OS, so it would have been inappropriate to deal with this detail at their level.\nunsigned long flags = 0; unsigned long mode = 0; unsigned long resolve = 0; #ifdef __NR_openat2 struct open_how how; syscall_get_arguments_deprecated(current, args-\u0026gt;regs, 2, 1, \u0026amp;val); res = ppm_copy_from_user(\u0026amp;how, (void *)val, sizeof(struct open_how)); if (unlikely(res != 0)) return PPM_FAILURE_INVALID_USER_MEMORY; flags = open_flags_to_scap(how.flags); mode = open_modes_to_scap(how.flags, how.mode); resolve = openat2_resolve_to_scap(how.resolve); #endif // ... There are a few takeaways here:\nFlags are converted in the internal representation before being pushed in the ring. This means that libscap expects data to be already encoded with the internal definitions. There is a conditional compilation for __NR_openat2. This small trick allows compiling the filler on old kernels that did not support openat2 syscall by simply stubbing the argument values to zero. This is more a compilation concern because the syscall will obviously not be caught by old kernel versions in the first place. When reading a pointer argument provided from the syscall caller, we need to copy the memory from userspace to kernel space, using ppm_copy_from_user, before being able to access it. eBPF probe Implementing the filler for the eBPF probe is just a matter of changing the function signature we used in the kernel module to use the FILLER macro instead.\n// driver/bpf/fillers.h FILLER(sys_openat2_x, true) { // ... return res; } The FILLER macro will declare an __bpf_sys_openat2_x inline function in the bpf section tracepoint/filler/\u0026lt;name\u0026gt;, that will be called from the sys_exit probe when the corresponding syscall gets intercepted. Please note that this redirection happens as an eBPF tail call. Details about the eBPF execution model are out of the scope of this post, but you can find some interesting resources here.\nThen, the body of the eBPF filler is implemented as a faithful copy of what we already did in the kernel module, by just the helper methods involved:\nsyscall_get_return_value -\u0026gt; bpf_syscall_get_retval syscall_get_arguments_deprecated -\u0026gt; bpf_syscall_get_argument val_to_ring -\u0026gt; bpf_val_to_ring ppm_copy_from_user -\u0026gt; bpf_probe_read At this point, even if you are lucky enough to compile all these changes on the first try, you can still expect the kernel to reject the newly produced eBPF probe. To guarantee its safety, the kernel has a verifier that checks the eBPF bytecode before actually launching it.\nThe technology is still at an early stage, and there is no explicit agreement between the clang compiler and the Linux kernel between the bytecode produced and the one accepted. Documentation on these aspects can be found on the web for further reference. The good news is that the filler functions are simple enough to avoid this kind of risk if implemented correctly.\nLibscap The only update that is required in libscap to support new syscalls is to add it in the records of g_syscall_info_table. This adds some context information on the syscall, that is used by libscap for its business logic.\n// userspace/libscap/syscall_info_table.c const struct ppm_syscall_desc g_syscall_info_table[PPM_SC_MAX] = { // ... /*PPM_SC_OPENAT2*/ { EC_FILE, (enum ppm_event_flags)(EF_NONE), \u0026#34;openat2\u0026#34; }, }; Libsinsp (optional) Indeed, libsinsp is one of the most complex components of Falco. It is responsible for parsing and filtering events, formatting output alerts, and maintaining an internal state. The process of adding a new syscall inside libsinsp is quite harder than what we saw so far. More specifically, there are no specific points in the codebase in which new code or metatada must be inserted. Instead, we must figure out which areas of the libsinsp business logic are affected by the introduction of the new syscall.\nIn this perspective, we started by trying to answer some fundamental questions. Should the syscall event be parsed in a specific way? Does the syscall introduce new event fields that we want to support in the filtering syntax? Must the syscall argument data be fetched, or retrieved, in a non-standard way? Does the syscall event alter the internal state or the cached values? None of these questions are easy to be addressed without some broad knowledge of the codebase of libsinsp. Accordingly, we proceeded by looking at some code areas that could be relevant for our purposes.\nAt a high level, the core job of libsinsp is to receive an event from libscap and then perform tasks related to parsing and filtering. Here, parsing means inspecting the event information, triggering internal state or cache changes, adding context metadata to the event, and calling some listener callbacks. Instead, the filtering part refers to the task of evaluating a boolean expression with the given event, to decide whether to discard it or not. Spoiler alert, it was not a surprise to discover that most of the business logic was dependent on the type of event and system call and that libsisnp processes each of them, case by case, with switch statements.\nFor context, the logic filters accepted by libsinsp look like the following:\nproc.name!=cat and evt.type=open This is a simple boolean expression, in which each term is an assertion between a field extracted from the event and an expected value. The supported operators can be found here: https://falco.org/docs/rules/conditions/#operators.\nParsing We started by looking at the sinsp_evt class that represents system events in the type hierarchy of libsinsp, which is a simple data container enriched by an extensive set of accessor methods.\n// userspace/libsinsp/event.cpp class SINSP_PUBLIC sinsp_evt : public gen_event { public: uint64_t get_ts(); uint16_t get_source(); uint16_t get_type(); // ... }; In that, we noticed the presence of some predicative getters for file-related operations, to which we suspected openat2 to be related. For reference, we updated the following method sinsp_evt::is_file_open_error. Notably, we had a strong hint on this method due to the presence of the openat constants inside the check. As such, we just appended the constants of openat2 inside the if statement.\nObserve that mimicking the way other already supported syscalls are processed is a good way of figuring out how to add new ones, and we used this trick extensively to understand the way libsinsp works.\nbool sinsp_evt::is_file_open_error() const { return (m_fdinfo == nullptr) \u0026amp;\u0026amp; ((m_pevt-\u0026gt;type == PPME_SYSCALL_OPEN_X) || // ... (m_pevt-\u0026gt;type == PPME_SYSCALL_OPENAT_X) || (m_pevt-\u0026gt;type == PPME_SYSCALL_OPENAT2_X)); } Then, inside the sinsp_parser::process_event method we noticed a pretty big switch statement over most of the supported event types. This method executes specific tasks for each different syscall and simplifies its job by grouping them into categories. In our case, we added our PPME_SYSCALL_OPENAT_2_X constant to fall in the sinsp_parser::parse_open_openat_creat_exit method (the constants for openat were already there). Since we also implemented our exit filler to be very similar to the one of openat, adding the PPME_SYSCALL_OPENAT2_X constant in a few if statements were enough to include our new syscall in the parsing flow. The source code of our pull request is pretty self-explanatory from this perspective.\nFiltering We start by giving a quick intro of how libsinsp filters the captured events. In the library, the filtering feature is implemented through the filter_check hierarchy. Instances of this class represent the terms of the user-specified boolean formulas to perform the actual checking. filter_checks are modeled to perform a single check over a single event field. The complete list of the supported event fields is visible by running Falco with the --l option. The sinsp_filter_check class is at the root of the hierarchy:\nclass sinsp_filter_check : public gen_event_filter_check { public: // ... virtual bool compare(sinsp_evt *evt); virtual uint8_t* extract(sinsp_evt *evt, OUT uint32_t* len, bool sanitize_strings = true) = 0; // ... }; Each child class of sinsp_filter_check represents one of the categories of event fields supported in Falco, such as fd.*, process.*, evt.*, and all the rest. The most relevant methods are compare and extract. The first is responsible for performing the actual field check, whereas the latter helps retrieve the field value in case it is not already present either in the event object or in the engine state.\nAs such, we have to figure out which filter_check we need to update with our new syscall. Again, following what was already done for openat was truly helpful. Long story made short, we had to update the extract methods of the sinsp_filter_check_fd and sinsp_filter_check_event. We also updated a string inside the sinsp_filter_check_event_fields table, which is where all the text information printed through the Falco --l option comes from.\nTesting At this point, we were sure to have written all the code required to support the openat2 syscall, but unfortunately, the work was far from being finished.\nOne of the first obstacles was compiling the source code over different versions of the Linux kernel and the compilers. We fixed our compilation issues through the aforementioned use of #ifdef statements in the kernel drivers and libscap, which made the build setup more robust. The openat2 syscall, and all the metadata related to it, are simply ignored if the underlying kernel version can't support it.\nAnother challenge was testing our work and verifying that Falco was able to monitor the new syscall. For this purpose, we wrote a small program making use of openat2. Something like the following snippet will suffice to do the testing for other syscalls too.\nint main(int argc, char** argv) { const char* pathname = \u0026#34;/tmp/openat2_test.bin\u0026#34;; struct open_how how; how.flags = O_CREAT | O_RDWR; how.mode = 07777; how.resolve = RESOLVE_BENEATH | RESOLVE_NO_MAGICLINKS; int res = syscall(SYS_openat2, AT_FDCWD, pathname, \u0026amp;amp;how, sizeof(struct open_how)); if(res == -1) perror(\u0026amp;#34;Could not call openat2\u0026amp;#34;); else printf(\u0026amp;#34;Result: %d\\n\u0026amp;#34;, res); return 0; } The testing setup is fairly simple. First, we had to compile Falco with the new version of libs, and we ran it with an ad-hoc ruleset that we were sure would trigger some alerts once our sample program was running. A rule filter such as evt.type=openat2 will suffice. Then, we ran the little program above and checked that Falco effectively sent some output alert (luckily, it did).\nWhoever reproduces the same experiment must be mindful of testing it with both the kernel module and the eBPF probe to assert that the feature parity guarantee of the two drivers gets respected.\nConclusion Honestly, we had tons of fun while working on this project. But this is just the beginning, as there are still plenty of syscalls to work on. Adding support to new system calls is always one of the best ways of contributing to Falco for three good reasons:\nThe monitoring capabilities of Falco increase with every new syscall it supports, and it becomes progressively harder to bypass its control. Supporting new syscalls requires the exploration of the whole stack of components that are part of Falco. This is a sublime way to quickly learn about the project and its inner structure. It's a fast and good way to contribute to a top-quality open source project and its community. You can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or even for a friendly chat!\nIf you would like to find out more about Falco:\nGet started in Falco.org Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":null,"title":"Monitoring new syscalls with Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-monitoring-new-syscalls/"},{"category":"blog","content":"Hello, fellow Falcoers! This blog introduces you to a new open system telemetry format and project called SysFlow. The project has deep ties to Falco, the de facto CNCF cloud-native runtime security project.\nFalco is exceptional at detecting unexpected application behavior and alerting on threats at runtime. Furthermore, its components and architecture open itself to creative uses.\nFor example, SysFlow embeds Falco's rich observability libraries into its cloud-native security telemetry stack and Falco's rules language to achieve data abstraction, behavioral analytics, and noise reduction.\nThe Falco project and the community helped make the SysFlow project a reality and we are excited to guide you through a deep dive today! Also, learn about how we integrated our solution with Falcosidekick to help diagnose alerts.\nWhat is SysFlow? SysFlow is a compact open telemetry format that records workload behaviors by connecting event and flow representations of process control flows, file interactions, and network communications. The resulting abstraction encodes a graph structure that enables provenance reasoning on host and container environments, and fast retrieval of security-relevant information.\nWhat challenges does it solve? The following are the key reasons that set SysFlow apart:\nReduces data footprints drastically when compared to raw system call collection. Reduces event fatigue (a.k.a. \u0026quot;too many alerts\u0026quot;) thanks to its underlying entity-relational model and flow abstractions. Minimizes the requirements for hard filters. Provides useful context by linking together system event data at the data format level. This expedites security analysis, enabling analytics beyond simple manual policies, including machine learning, stateful analytics, and automated policy generation. Treats system security monitoring as a data science problem through rapid edge analytics building, easy-to-use APIs, and support for multiple data serialization and export formats. Built on Falco libs The SysFlow format is supported by an edge processing pipeline that aggregates event provenance information and supports real-time enrichment of the telemetry stream with attack TTP labels, environment metadata, and Kubernetes log data.\nAs a benefit of using the Sysflow format, users go from managing individual events generated from different sources to obtaining an enhanced dataset to work with, enabling them to focus on writing and sharing analytics on a scalable, common open source platform.\nThe framework builds on Falco libs and the Falco rules language to create the plumbing required for system telemetry as shown in the diagram below.\nFalco libs facilitate the collection of system events generated from the host and containers through the eBPF probe in the kernel space.\nAt user level, the SysFlow Collector, also leveraging Falco libs, collects the previous events and exports the captured information using Apache Avro object serialization.\nThe SysFlow Processor processes and enriches the data. The policy engine applies logical rules to filter, alert or semantically label sysflow records using a declarative language based on Falco rules.\nThe SysFlow framework is designed as a pluggable edge processing architecture, which includes a policy engine, and what's more noteworthy, an experimental graph engine.\nThe policy engine accepts declarative policies (written in Falco rules syntax) and supports edge filtering, tagging, and alerting on SysFlow streams.\nAnd a visual addition is the experimental graph engine, which clusters and exports concise behavioral profiles of monitored applications. We'll see an example in a moment.\nBeyond the built-in plugins and exporters provided in the SysFlow stack, users can write and plug their own real-time analytics, and consume new telemetry sources using our Golang APIs. The framework also includes Python packages and a pre-built Jupyter container to facilitate interactive SysFlow data exploration.\nFalco Sidekick integration Falco Sidekick is a relatively young project but has already harnessed 3.7M pulls on Docker Hub!\nAt its core, it's a simple daemon for connecting Falco events to many different ecosystems, like a Swiss Army Knife of sorts. It also provides an intuitive web user interface for event visualization and filtering.\nTo demonstrate how SysFlow can extend Falco's capabilities, we have been working on an experimental integration with Falco Sidekick.\nThe complete ecosystem includes:\nThe SysFlow telemetry stack with a new exporter encoder for Falco events. A searchable back store based on S3. Apache Druid, and new extensions to Falco Sidekick for visualizing and interactively querying SysFlow process graphlets. The Falco Sidekick integration in action To illustrate how all these components fit together, let's consider the following scenario:\nIt shows an attack in which a cybercriminal exfiltrates data from a Kubernetes service.\nDuring reconnaissance, the attacker detects a vulnerable node.js service that is susceptible to a remote code execution attack exploiting a vulnerability in an node.js module. The attacker exploits the system using a malicious payload, which hijacks the node.js server. The attacker then downloads a python script from a remote server. The script contacts its command-and-control server), and then starts scanning the system for sensitive keys. The attacker eventually gains access to a sensitive customer database. The attack completes when data is exfiltrated off site. In this setup, the SysFlow monitors the Kubernetes cluster and outputs alerts to Falco Sidekick, which are annotated with an ID (\u0026quot;sf.graphid\u0026quot;) referencing compact behavioral graphs labeled with MITRE ATT\u0026amp;CK metadata that can help diagnose alerts.\nAs a proof-of-concept, we customized Falco Sidekick's web interface to fetch and display the graph associated with an event. For example, the screenshot below shows the precise infection point in which the benign node.js application has been hijacked into spawning an attack script.\nBased on this alert, we can further investigate the potential threat using our interactive Jupyter environment. Typically, the first step in this diagnosis routine is to craft a hypothesis, or indicator, based on the original event. The syntax follows the rules condition language used in the SysFlow policy engine. A reasonable hypothesis would be to query for network and filesystem activity associated with processes containing the string \u0026quot;exfil\u0026quot; in its command line.\nApplying this indicator fetches a new graph from the storage backend that shows that the attack script was executed and has been busy interacting with the filesystem and communicating over the network.\nSuspicious, huh?\nSince data exfiltration is of immediate concern, we can use the SysFlow APIs to quickly glance over the ingress and egress traffic associated with this process. We immediately recognize a periodic pattern in the network flows, which is indicative of command-and-control behavior, such as beaconing. We also see a suspiciously high outbound traffic at the end of the communication, which surely deserves further attention.\nWe close our investigation by projecting the SysFlow trace associated with the above graph across different components, including container and network primitives. Two types of flows are of particular interest to us here: the backend flow from 172.30.106.11:3000 (internal object storage endpoint) that connects to the egress flow 104.244.42.*:443 (external exfiltration endpoint) through container bc3e.\nConclusion This integration is still experimental, but we are excited about the possibilities it holds and reminds us how well the Falco architecture makes it possible to use it in a creative way that is SysFlow. The goal is to refine this proof-of-concept to inform our future contributions to Falco. For example, a natural next step is to work on a SysFlow library and plugin for the incubating libs plugin system.\nWhere to learn more If you would like to learn more about SysFlow:\nGet started in sysflow.io Check our past research papers and presentations. Check out the SysFlow organization in github. Meet us on the SysFlow Slack (we are also active on the Falco Slack channel!). You can learn more about Falco as well:\nGet started in Falco.org Check out the Falco project in GitHub Get involved with the Falco community Meet the maintainers on the Falco Slack Follow @falco_org on Twitter We look forward to your feedback and contributions! PRs are welcome!\n","summary":"","tags":null,"title":"Cloud-Native Observability and Security Analytics with SysFlow and Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/sysflow-falco-sidekick/"},{"category":"blog","content":"GitLab covers the entire software development lifecycle in a single application: From managing, coding, deploying and securing, without forgetting collaboration. However, achieving velocity with confidence, security without sacrifice, and visibility in such a dynamic environment is not always an easy task.\nIt is GitLab's mission to make it so that everyone can contribute. One key aspect to achieve this was to protect the integrity of its own software supply chain. To secure the GitLab DevOps platform, Dennis Appelt, Staff Security Engineer at GitLab, came up with an incredibly elegant and straight-forward solution based on the open source project Falco: GitLab's Package Hunter.\nBefore making it open source, GitLab had been testing Package Hunter internally since November 2020. They chose Falco, for its performance as well as for its reliability and reputation in the runtime security field.\nHow Package Hunter works In the DevOps world, software is mainly developed by using third party components. It is practically impossible to manually test and verify every single line of external code, and automated code scanning tools can only look for known malicious patterns.\nHere it is when GitLab came with the idea of performing dependency analysis by inspecting the behaviour of the code at runtime in a controlled isolated environment, to see if there was any odd activity.\nAdding this step to a continuous integration (CI) pipeline can give the confidence that the building blocks of the software will remain uncorrupted with every new artifact build.\nWhat role plays Falco in Package Hunter There are plenty of tools to search for known vulnerabilities that could be used to analyse code and binary objects. Unfortunately, new vulnerabilities come up every day or they could have been hidden for years. Falco approaches the issue from a different angle by inspecting what your code actually does in runtime, where processes and libraries interact with the operating system.\nNow, for Falco to report on unfamiliar behaviour, the code needs to run along with Falco. Package Hunter is in charge of creating a dedicated containerised environment to test the dependencies and lets Falco do its magic in the background. Package Hunter uses Falco results to report back to the user, who can react accordingly.\nBy using Falco rules, plus some customised ones to fulfil GitLab's requirements, and a collection of malicious indicators that engineers saw in the wild, it can quickly see potentially harmful activity, such as unexpected outbound network connections, undesired writing attempts, and many others.\nPackage Hunter also enables GitLab to simulate attacks, similar to what it sees in the wild by using some of the most high-profile events. The simulations enable the company to quickly identify issues before they become real problems, giving GitLab engineers the highest degree of confidence about the code they are running.\nFirst steps with Package Hunter Let's take a look at how this process works, by deploying Package Hunter and performing a quick test.\nAt the moment, Package Hunter requires a dedicated server where the application offers an API to send the dependencies under test to.\nWe can deploy Package Hunter either to a dedicated server or, even better, a disposable Vagrant environment set up following these steps::\n$ git clone https://gitlab.com/gitlab-org/security-products/package-hunter.git $ cd package-hunter $ vagrant up The Vagrantfile provided within the repository contains instructions to provision the Package Hunter server until a first stage. However, to start the application we need to execute one or two more commands inside the virtual machine.\nPay attention, we will execute npm ci from the /vagrant folder inside the virtual machine, that is mapped to the package-hunter git repository in our host machine.\n$ vagrant ssh $ cd /vagrant $ npm ci The npm ci command will set up our Package Hunter server with the latest version of packages and dependencies.\nTo actually start the application execute:\n$ NODE_ENV=development DEBUG=pkgs* node src/server.js Package Hunter is now running.\nSince we haven't created any kind of external access to the machine and to keep our workstation clean, we will do our first test from inside the Vagrant machine itself.\nFor that, we will use the contents of the directory falco-test from the repository, which are conveniently mounted under /vagrant.\nWarning, we want to start a second session in the virtual machine, so don't interrupt the server running in the previous one.\n$ vagrant ssh $ tar -C /vagrant/falco-test -czf /home/vagrant/falco-test.tgz . $ curl -v -H \u0026#39;Content-Type: application/octet-stream\u0026#39; --data-binary @falco-test.tgz http://localhost:3000/monitor/project/npm Trying ::1… TCP_NODELAY set Connected to localhost (::1) port 3000 (#0) \u0026gt; POST /monitor/project/npm HTTP/1.1 \u0026gt; Host: localhost:3000 \u0026gt; User-Agent: curl/7.58.0 \u0026gt; Accept: / \u0026gt; Content-Type: application/octet-stream \u0026gt; Content-Length: 2868 \u0026gt; Expect: 100-continue \u0026gt; \u0026lt; HTTP/1.1 100 Continue We are completely uploaded and fine \u0026lt; HTTP/1.1 200 OK \u0026lt; X-Powered-By: Express \u0026lt; Content-Type: application/json; charset=utf-8 \u0026lt; Content-Length: 59 \u0026lt; ETag: W/\u0026#34;3b-i8XJXwHQknoVSzLQsCo9FYtlE6Y\u0026#34; \u0026lt; Date: Fri, 19 Nov 2021 16:35:15 GMT \u0026lt; Connection: keep-alive \u0026lt; Keep-Alive: timeout=5 \u0026lt; * Connection #0 to host localhost left intact {\u0026#34;status\u0026#34;:\u0026#34;ok\u0026#34;,\u0026#34;id\u0026#34;:\u0026#34;633414e2-24f2-412a-811f-c37131ff2c61\u0026#34;} Package Hunter has acknowledged our request, confirmed that the falco-test.tgz file has been received and it will start to asynchronously scan in the background.\nUsing the id returned from the curl connection, we can poll the server as often as we want. Once the status field becomes finished we can retrieve the results of the scan:\n$ curl http://localhost:3000/?id=633414e2-24f2-412a-811f-c37131ff2c61 | json_pp { \u0026#34;id\u0026#34; : \u0026#34;633414e2-24f2-412a-811f-c37131ff2c61\u0026#34;, \u0026#34;status\u0026#34; : \u0026#34;finished\u0026#34;, \u0026#34;result\u0026#34; : [ … { \u0026#34;output\u0026#34; : \u0026#34;16:35:16.457772674: Notice Disallowed outbound connection destination (command=wget -qO- https://gitlab.com/snippets/1890615/raw connection=172.17.0.2:54865-\u0026gt;172.65.251.78: \u0026#34;time\u0026#34; : { \u0026#34;seconds\u0026#34; : \u0026#34;1637339716\u0026#34;, \u0026#34;nanos\u0026#34; : 457772674 }, \u0026#34;source\u0026#34; : \u0026#34;SYSCALL\u0026#34;, \u0026#34;hostname\u0026#34; : \u0026#34;vagrant\u0026#34;, \u0026#34;output_fields\u0026#34; : { \u0026#34;container.id\u0026#34; : \u0026#34;c62400ffae4a\u0026#34;, \u0026#34;user.name\u0026#34; : \u0026#34;root\u0026#34;, \u0026#34;proc.cmdline\u0026#34; : \u0026#34;wget -qO- https://gitlab.com/snippets/1890615/raw\u0026#34;, \u0026#34;fd.name\u0026#34; : \u0026#34;172.17.0.2:54865-\u0026gt;172.65.251.78:0\u0026#34;, \u0026#34;container.image.repository\u0026#34; : \u0026#34;maldep\u0026#34;, \u0026#34;container.name\u0026#34; : \u0026#34;some-container-633414e2-24f2-412a-811f-c37131ff2c61.tgz\u0026#34;, \u0026#34;evt.time\u0026#34; : \u0026#34;16:35:16.457772674\u0026#34; }, \u0026#34;priority\u0026#34; : \u0026#34;NOTICE\u0026#34;, \u0026#34;rule\u0026#34; : \u0026#34;Unexpected outbound connection destination\u0026#34; }, { \u0026#34;hostname\u0026#34; : \u0026#34;vagrant\u0026#34;, \u0026#34;priority\u0026#34; : \u0026#34;NOTICE\u0026#34;, \u0026#34;rule\u0026#34; : \u0026#34;Unexpected outbound connection destination\u0026#34;, \u0026#34;output_fields\u0026#34; : { \u0026#34;evt.time\u0026#34; : \u0026#34;16:35:16.490784795\u0026#34;, \u0026#34;container.image.repository\u0026#34; : \u0026#34;maldep\u0026#34;, \u0026#34;proc.cmdline\u0026#34; : \u0026#34;wget -qO- https://gitlab.com/snippets/1890615/raw\u0026#34;, \u0026#34;container.name\u0026#34; : \u0026#34;Some-container-633414e2-24f2-412a-811f-c37131ff2c61.tgz\u0026#34;, \u0026#34;fd.name\u0026#34; : \u0026#34;172.17.0.2:48644-\u0026gt;172.65.251.78:443\u0026#34;, \u0026#34;container.id\u0026#34; : \u0026#34;c62400ffae4a\u0026#34;, \u0026#34;user.name\u0026#34; : \u0026#34;root\u0026#34; }, \u0026#34;output\u0026#34; : \u0026#34;16:35:16.490784795: Notice Disallowed outbound connection destination (command=wget -qO- https://gitlab.com/snippets/1890615/raw connection=172.17.0.2:48644-\u0026gt;172.65.251.78: \u0026#34;source\u0026#34; : \u0026#34;SYSCALL\u0026#34;, \u0026#34;time\u0026#34; : { \u0026#34;seconds\u0026#34; : \u0026#34;1637339716\u0026#34;, \u0026#34;nanos\u0026#34; : 490784795 } }, … ] } As you saw, the output from the previous command recalls the logs generated by Falco. These are retrieved from the Falco service by the Package Hunter application using the Falco gRPC API. As an example, from this snippet we can obtain interesting information like:\nWhich rule was triggered: Unexpected outbound connection destination What command generated it: wget ... To which host it tries to connect: 172.65.251.78:443 and many other different items, always depending on the triggered rule. The Falco rules that were triggered during our test are completely customisable. Every time new rules are added to Falco, they also extend the range of issues recognised by Package Hunter.\nUsing Falco to secure all the development cycle Package Hunter is one open source project that uses Falco, but it is not the only project in GitLab that uses it.\nGitLab also incorporated Falco into some of the core product capabilities of the GitLab Ultimate tier, the most comprehensive level of service offered by GitLab.\nFor instance, GitLab's Security Orchestration capabilities incorporate Falco. Led by Sam White, Senior Product Manager – Protect Stage, the solution provides a unified security policy editor and an alert dashboard to manage security scanning and monitoring from development all the way through deployment and production. Security Orchestration offers users the ability to write policies to improve security posture, enforce policies, and generate alerts when potentially malicious activity occurs.\nThe strategy behind the alerts is very simple: Monitor activity to watch for signs of unusual behavior. If there is something bad, block it; and push to manual review those events that you're not confident about. The key is to have the right rules in place, so GitLab isn't overloading manual reviewers and getting in the way of the business.\nGitLab is also doing some heavy lifting with runtime protection in production. Though security and development teams use the same platform, Security Orchestration enables duties to be separated. Security teams can require scans, and developers have visibility into those scans directly —without modifying or disabling them— thus supporting better compliance. Falco enables users to manage their own rules within GitLab and enforce them within the production cluster.\nConclusion Falco runs throughout the security DNA at GitLab – but why? Sam White explained it with two words: \u0026quot;Cloud Native\u0026quot;. It's the predominant reason for the choice, and when paired with Kubernetes blocking and enforcement capabilities, users can monitor system logs, new network connetions and file integrity, do application allow listing, and manage those rules easily. Plus, users have a clear history of who changed what policies and can even implement a two-step approval process for all changes.\nTo learn more about Package Hunter:\nMeet Package Hunter Check out the Package Hunter project in GitLab Take the first steps with Package Hunter Visit https://about.gitlab.com If you would like to find out more about Falco:\nGet started in Falco.org Check out the Falco project in GitHub. Get involved with the Falco community Meet the maintainers on the Falco Slack Follow @falco_org on Twitter ","summary":"","tags":null,"title":"Discover how GitLab uses Falco to detect abnormal behaviour in code dependencies","url":"https://v0-43--falcosecurity.netlify.app/blog/gitlab-falco-package-hunter/"},{"category":"blog","content":"One of the upcoming features in Falco that we're really excited about is the ability to extend Falco's functionality by using plugins. We'll be demoing this capability during Kubecon North America 2021. Specifically, we'll be showing the support for AWS Cloudtrail logs in Falco, with a Cloudtrail plugin and related falco rules that can do the following:\nRead Cloudtrail logs and return them as events Identify suspicious or notable activities in Cloudtrail logs. The feature itself is still in very early access, and we expect it will be officially released early next year. In the meantime, we'd like to get potential plugin developers to take a look at the APIs and provide feedback while we move forward towards an official release.\nWhat Are Plugins? Plugins are shared libraries that conform to a documented API and come in two flavors:\nSource Plugins add new event sources/filter fields that can be evaluated using filtering expressions/Falco rules. Extractor Plugins add the ability to define new fields that can extract information from either core Falco events or events generated by other plugins. These two flavours of plugins are expected to dramatically extend the functionality of Falco, allowing users to write rules for almost any kind of streaming data.\nA plugin can be written in any language, as long as the language supports exposing C function interfaces that can be called from a C/C++ program like Falco. We've written plugins in C, C++, and Go using this interface. For Go, we've also written a module that handles some of the work of translation between C pseudo-types and Go types, as well as providing convenience methods that make it easier to write plugins in Go.\nSource Plugins A source plugin provides a new event source. It has the ability to \u0026quot;open\u0026quot; and \u0026quot;close\u0026quot; a session that provides events. It also has the ability to return an event to the plugin framework via a next() method.\nSource plugins also have the ability to extract information from events based on fields. For example, given a syscall event, a field proc.name can extract a process name such as ngnix. The plugin returns a set of supported fields, and there are functions to extract a value given an event and field. The plugin framework can then build filtering expressions/Falco rule conditions based on these fields combined with relational and/or logical operators. For example, let us consider an expression, ct.name=root and ct.region=us-east-1. The plugin framework handles parsing the expression, calling the plugin to extract values for fields ct.name/ct.region for a given event, and determining the result of the expression. In a Falco output string, such as An EC2 Node was created (name=%ct.name region=%ct.region), the plugin framework handles parsing the output string, calling the plugin to extract values for fields, building the resolved string, and replacing the template field names (e.g. %ct.region) with values (e.g. us-east-1).\nExtractor Plugins An extractor plugin focuses only on field extraction from events generated by other plugins or by the core libraries. It does not provide an event source, but can extract fields from other event sources. An example is json field extraction, where a plugin might be able to extract fields from arbitrary json payloads.\nWe've written a JSON extractor plugin that can extract arbitrary data from json payloads, using JSON Pointers.\nPlugin Events In Capture Files Plugin events are compatible with .scap capture files and can be read by Falco and read/written by userspace tools like sysdig that use the Falco libraries. A new event type \u0026quot;pluginevent\u0026quot; contains a plugin id and an arbitrary payload returned by the plugin. This allows leveraging existing support for capture files in the Falco libraries. A capture file can potentially contain a mix of system call and plugin events in the same file. You can even read capture files generated by plugins in tools like wireshark!\nPlugin Event Sources and Interoperability With the introduction of plugins, there's the potential for many new kinds of events and many new fields that can extract information from events. With that in mind, we've formalized how rules are matched to events in Falco.\nEvents returned by source plugins have an \u0026quot;event source\u0026quot; which describes the information in the event. This is distinct from the plugin name to allow for multiple kinds of plugins to generate the same kind of events. For example, there might be plugins gke-audit-bridge, eks-audit-bridge, ibmcloud-audit-bridge, and so on that can fetch K8s Audit information. The plugins would be distinct with their own shared libraries and implementations, but would have the same event source k8s_audit.\nWhen Falco loads rules, it reads the source: property and tries to match the event source with a loaded source and/or extractor plugin. If a source plugin that supports the event source is loaded, all rules with that particular source will be evaluated for events coming from that source plugin.\nExtractor plugins are handled slightly differently. An extractor plugin optionally provides a set of compatible event sources. When the framework receives an event with an event source that is in the compatible event sources list, fields in expressions/Falco outputs will be extracted from events using the extractor plugin. An extractor plugin can also not name a set of event sources. In this case, all events will be presented to the extractor plugin, regardless of source. In this case, the extractor plugin must detect the format of arbitrary payloads and be able to return NULL/no value when the payload is not supported.\nConfiguring Plugins in Falco Plugins are configured in yaml via new falco.yaml properties plugins and load_plugins. Here's an example:\nplugins: - name: cloudtrail library_path: cloudtrail/plugin.so init_config: \u0026#34;...\u0026#34; open_params: \u0026#34;...\u0026#34; - name: json library_path: json/plugin.so init_config: \u0026#34;\u0026#34; open_params: \u0026#34;\u0026#34; # Optional load_plugins: [cloudtrail, http_json] The plugins property in falco.yaml defines the set of plugins that can be loaded by Falco. The property contains a list of plugin definitions. Each plugin definition has:\nname: The name of the plugin. library_path: The path to the shared library of the plugin. init_config: A configuration string (typically JSON) that is passed to the plugin when the plugin is initialized. open_params: A configuration string that is passed to the plugin when the plugin open()s a new stream of events. By default, every plugin in the plugins list will be loaded. If present, the load_plugins property contains specific name entries from plugins that are loaded instead.\nRunning Plugins in Falco For now, when plugin support is enabled, Falco's core support for syscalls is disabled. Additionally, only a single source plugin can be loaded at once. If multiple source plugins are loaded, falco will return an error. Any number of extractor plugins can be loaded at once.\nWe intend to relax these restrictions to allow running multiple source plugins at once. It will happen when we tackle the concurrency, fairness, and resource utilization issues that result from having multiple streams of events being processed by a single Falco rules engine.\nCloudtrail Plugin In addition to the introduction of plugins support, we've written a source plugin cloudtrail that can read Cloudtrail logs and pass them to the rules engine as events.\nThe plugin can be configured to obtain log files in a number of ways, depending on the open_params value in falco.yaml:\nA S3 bucket: s3://\u0026lt;S3 Bucket Name\u0026gt;[/\u0026lt;Optional Prefix\u0026gt;]. A SQS queue that passes along SNS notifications about new log files: sqs://\u0026lt;SQS Queue Name\u0026gt; A local filesystem path: Any path. The plugin also exports fields that extract information from a cloudtrail event, such as the event time, the aws region, S3 bucket/EC2 instance name, etc.\nThe plugin uses the same authentication mechanisms used by the AWS Go SDK:\nEnvironment Variables: Specify the AWS region with AWS_REGION=xxx, the access key id with AWS_ACCESS_KEY_ID=xxx, and the secret key with AWS_SECRET_ACCESS_KEY=xxx. Shared Configuration Files: Specify the AWS region in a file at $HOME/.aws/config and the credentials in a file at $HOME/.aws/credentials. New Rules for AWS Cloudtrail In addition to the plugin, we've created new Falco rules that look for suspicious, notable, and interesting activities in the Cloudtrail logs. Here is an example rule for Multi-Factor Authentication, Console Login Without MFA:\n- rule: Console Login Without MFA desc: Detect a console login without MFA. condition: ct.name=\u0026#34;ConsoleLogin\u0026#34; and ct.error=\u0026#34;\u0026#34; and json.value[/userIdentity/type]!=\u0026#34;AssumedRole\u0026#34; and json.value[/responseElements/ConsoleLogin]=\u0026#34;Success\u0026#34; and json.value[/additionalEventData/MFAUsed]=\u0026#34;No\u0026#34; output: Detected a console login without MFA (requesting user=%ct.user, requesting IP=%ct.srcip, AWS region=%ct.region) priority: CRITICAL source: aws_cloudtrail The rule source is aws_cloudtrail. When Falco is run with a loaded Cloudtrail plugin, it will evaluate these rules because the plugin event source matches the source in the rule. The fields ct.name, ct.error, ct.srcip, etc are resolved by the plugin via a call to the plugin's extract fields function. For example, matching ct.name with \u0026quot;ConsoleLogin\u0026quot; indicates a console login attempt. The full set of fields supported by the Cloudtrail plugin are in the README.\nThe JSON plugin can also be used because the underlying event payload is JSON with this format. The JSON plugin can use its json.value field, which takes a JSON pointer as argument, to extract any part of the JSON object. For example, matching json.value[/responseElements/ConsoleLogin] with \u0026quot;Success\u0026quot; represents a successful login attempt, and json.value[/additionalEventData/MFAUsed] with \u0026quot;No\u0026quot; represents a console login where MFA was not used.\nWhen an event matches this rule, Falco will emit an alert that can be sent to a file, stdout, syslog, etc. as well as Falcosidekick:\n00:40:32.000000000: Critical Detected a console login without MFA (requesting user=bob.user, requesting IP=192.0.2.24, AWS region=us-east-1) Current Set of Cloudtrail Rules Here is the full set of rules we've written so far. When the feature is fully released, they will be in a file aws_cloudtrail_rules.yaml in the falco release. The rules cover detecting any change (\u0026quot;Create Group\u0026quot;, \u0026quot;Create Lambda Function\u0026quot;), detecting specific misconfigurations/bad practices (\u0026quot;Console Login Without MFA\u0026quot;, \u0026quot;Delete Bucket Encryption\u0026quot;), and checking against lists of allowed/disallowed values (\u0026quot;Run Instances in Non-approved Region\u0026quot;). We would love additional rule contributions from the community!\nConsole Login Through Assume Role Console Login Without MFA Console Root Login Without MFA Deactivate MFA for Root User Create AWS user Create Group Delete Group ECS Service Created ECS Task Run or Started Create Lambda Function Update Lambda Function Code Update Lambda Function Configuration Run Instances Run Instances in Non-approved Region Delete Bucket Encryption Delete Bucket Public Access Block List Buckets Put Bucket ACL Put Bucket Policy CloudTrail Trail Created CloudTrail Logging Disabled Learn More Hopefully by now you're excited to learn more about plugins and how to author your own plugin. During this early access period, you can take a look at the preview docs, which go into greater detail on the plugins architecture and implementation details. Also, we've written a developer's guide that documents each API function, walks through the code of two example plugins, and discusses some best practices for writing plugins.\nHave fun and let us know what you think!\n","summary":"","tags":null,"title":"Falco Plugins Early Access","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-plugins-early-access/"},{"category":"blog","content":"Today we announce the fall release of Falco 0.30.0 🌱\nThis version includes new features, important fixes, and an exciting proposal for a libs plugin system!\nNovelties 🆕 Let's review some of the highlights of the new release.\nNew features and fixes This release introduces a new --k8s-node command-line option (#1671), which allows filtering by node name when requesting pod metadata to the K8s API server. Typically, it should be set to the node on which Falco runs. If empty, no filter is set, which may incur a performance penalty on large clusters. This new feature represents a significant performance improvement for Falco, and closes a long-waited fix to the issue confirmed by many deployments of Falco on production-scale Kubernetes clusters.\nThe update to the drivers version 3aa7a83 completes the performance enhancements for the collection of metadata from container orchestrators, and includes improvements to libsinsp public API, allowing consumers to modify the key parameters that determine the behavior of metadata collection from orchestrators like Kubernetes or Mesos. These parameters are now exposed as customizable settings in Falco, enabling users to tune metadata fetching behavior to their deployments. The default values are:\nmetadata_download: max_mb: 100 chunk_wait_us: 1000 watch_freq_sec: 1 This release also adds the ability to export rule tags and event source in gRPC and JSON outputs! This behavior can be configured, and enables Falco event consumers, such as Falco Sidekick, to take full advantage of Falco's event tagging feature. Happy tagging :)\nLibs plugin system proposal A proposal for a libs plugin system has been accepted, and we couldn't be more excited! The possibilities are limitless! 🎉\nPlugins will allow users to easily extend the functionality of the libraries and, as a consequence, of Falco and any other tool based on the libraries. This proposal, in particular, focuses on two types of plugins: source plugins and extractor plugins. A source plugin implements a new sinsp/scap event source (e.g., \u0026quot;k8s_audit\u0026quot;), while an extractor plugin focuses on field extraction from events generated by other plugins, or by the core libraries.\nPlugins are dynamic libraries (.so files in Unix, .dll files in windows) that export a minimum set of functions that the libraries will recognize. They can be written in any language, as long as they export the required functions. Go, however, is the preferred language to write plugins, followed by C/C++. To facilitate the development of plugins, a golang SDK has been developed.\nBoth the experimental plugin system and SDK are now incubating projects in the Falco organization, and include a set of initial examples. We invite the community to try them out, contribute new plugins, and join efforts to build together the foundation for cloud-native runtime security! 🚀\nNew Falco release schedule Finally, after discussing with the community, a new release schedule has been approved for Falco. New releases are now due to happen three times per year: at the end of January, May, and September. We will continue to release hot fixes and minor patches in between major releases. As always, feedback, bug reports, and contributions are welcome! :)\nTry it! As usual, in case you just want to try out the stable Falco 0.30.0, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nYou can also find the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader What's next 🔮 Falco 0.31.0 is anticipated to be released in January 2022!\nAs usual, the final release date will be discussed during the Falco Community Calls.\nLet'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!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors! Falco reached 100 contributors, and all the other Falco projects are receiving a vital amount of contributions every day.\nSpecial kudos to Falco Sidekick, which just passed the mark of 1.5M docker pulls on docker hub!\nKeep up the good work!\nBye!\nFred\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.30.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-30-0/"},{"category":"blog","content":" This blog post is part of a series of articles about how to create a Kubernetes response engine with Falco, Falcosidekick and a FaaS.\nSee other posts:\nKubernetes Response Engine, Part 1 : Falcosidekick + Kubeless Kubernetes Response Engine, Part 2 : Falcosidekick + OpenFaas Kubernetes Response Engine, Part 3 : Falcosidekick + Knative Kubernetes Response Engine, Part 4 : Falcosidekick + Tekton Kubernetes Response Engine, Part 5 : Falcosidekick + Argo Kubernetes Response Engine, Part 6 : Falcosidekick + Cloud Run Kubernetes Response Engine, Part 7 : Falcosidekick + Cloud Functions Kubernetes Response Engine, Part 8: Falcosidekick + Flux v2 The earlier posts in this series, show how to use Kubeless, Argo, Knative, and others to trigger a resource after getting input from Falcosidekick. Recently, Falcosidekick received a new output type support for Fission.\nIn this blog post, we will cover using Falcosidekick and Fission to detect and delete a compromised pod in a Kubernetes cluster. We will briefly talk about Fission in this blog, however, you can check the complete documentation here.\nPrerequisites We need tools with the following minimum versions to achieve this demo:\nMinikube v1.19.0 Helm v3.5.4 kubectl v1.21.0 fission-cli v1.13.1 Provision local Kubernetes Cluster There are various ways to provision a local Kubernetes cluster such as, KinD, k3s, k0s, Minikube, etc. We are going to use Minikube in this walkthrough.\nLet's get provisioned a local Kubernetes cluster:\n$ minikube start --cpus 3 --memory 8192 --vm-driver virtualbox 😄 minikube v1.19.0 on Darwin 10.15.7 ✨ Using the virtualbox driver based on user configuration 👍 Starting control plane node minikube in cluster minikube 🔥 Creating virtualbox VM (CPUs=3, Memory=8192MB, Disk=20000MB) ... 🐳 Preparing Kubernetes v1.20.2 on Docker 20.10.4 ... ▪ Generating certificates and keys ... ▪ Booting up control plane ... ▪ Configuring RBAC rules ... 🔎 Verifying Kubernetes components... ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5 🌟 Enabled addons: storage-provisioner, default-storageclass 🏄 Done! kubectl is now configured to use \u0026#34;minikube\u0026#34; cluster and \u0026#34;default\u0026#34; namespace by default Install Fission Fission is a fast, open source serverless framework for Kubernetes with a focus on developer productivity and high performance. Fission operates on just the code: Docker and Kubernetes are abstracted away under normal operation, though you can use both to extend Fission if you want to.\nFollow the official documentation for deploying Fission to Kubernetes.\nHere we will be using Helm to install Fission:\n$ export FISSION_NAMESPACE=\u0026#34;fission\u0026#34; $ kubectl create namespace $FISSION_NAMESPACE $ kubectl create -k \u0026#34;github.com/fission/fission/crds/v1?ref=1.13.1\u0026#34; $ helm repo add fission-charts https://fission.github.io/fission-charts/ $ helm repo update $ helm install --version 1.13.1 --namespace $FISSION_NAMESPACE fission fission-charts/fission-all NAME: fission LAST DEPLOYED: Wed Jul 21 18:03:44 2021 NAMESPACE: fission STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: 1. Install the client CLI. Mac: $ curl -Lo fission https://github.com/fission/fission/releases/download/1.13.1/fission-1.13.1-darwin-amd64 \u0026amp;\u0026amp; chmod +x fission \u0026amp;\u0026amp; sudo mv fission /usr/local/bin/ Linux: $ curl -Lo fission https://github.com/fission/fission/releases/download/1.13.1/fission-1.13.1-linux-amd64 \u0026amp;\u0026amp; chmod +x fission \u0026amp;\u0026amp; sudo mv fission /usr/local/bin/ Windows: For Windows, you can use the linux binary on WSL. Or you can download this windows executable: https://github.com/fission/fission/releases/download/1.13.1/fission-1.13.1-windows-amd64.exe 2. You\u0026#39;re ready to use Fission! # Create an environment $ fission env create --name nodejs --image fission/node-env # Get a hello world $ curl https://raw.githubusercontent.com/fission/examples/master/nodejs/hello.js \u0026gt; hello.js # Register this function with Fission $ fission function create --name hello --env nodejs --code hello.js # Run this function $ fission function test --name hello Hello, world! Check if everything is working before moving onto the next step:\n$ kubectl get pods --namespace fission NAME READY STATUS RESTARTS AGE buildermgr-5698c89fff-rk9z6 1/1 Running 0 7m20s controller-5dcb44bcd6-vq9hb 1/1 Running 0 7m20s executor-6b6d6469d6-2xrlk 1/1 Running 0 7m20s fission-kube-state-metrics-5fc9bd6684-7ffwp 1/1 Running 0 7m20s fission-prometheus-alertmanager-65f5574885-tlrz6 2/2 Running 0 7m20s fission-prometheus-node-exporter-jd9w6 1/1 Running 0 7m20s fission-prometheus-node-exporter-jpzn8 1/1 Running 0 7m20s fission-prometheus-node-exporter-rb25l 1/1 Running 0 7m20s fission-prometheus-pushgateway-54c87b5796-28x2h 1/1 Running 0 7m20s fission-prometheus-server-9d64c74b4-ld97h 2/2 Running 0 7m20s influxdb-59649c8c6-5vx54 1/1 Running 0 7m20s kubewatcher-6996fccc6b-5vbvx 1/1 Running 0 7m20s logger-6kdw4 2/2 Running 0 7m20s logger-nmw9t 2/2 Running 0 7m20s logger-zkrq9 2/2 Running 0 7m20s mqtrigger-keda-7584989c48-n5w6g 1/1 Running 0 7m20s mqtrigger-nats-streaming-664c55c979-t9gp5 1/1 Running 0 7m19s nats-streaming-6c6d7c6fbf-ft468 1/1 Running 0 7m20s router-5c5c6cbb87-989pc 1/1 Running 0 7m20s storagesvc-57ccf58976-qcr4d 1/1 Running 0 7m19s timer-794b89579b-6kxwx 1/1 Running 0 7m20s Install Falco + Falcosidekick Firstly, we'll create the namespace that will host both Falco and Falcosidekick:\n$ kubectl create namespace falco We add the helm repo:\n$ helm repo add falcosecurity https://falcosecurity.github.io/charts \u0026#34;falcosecurity\u0026#34; has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the \u0026#34;falcosecurity\u0026#34; chart repository ...Successfully got an update from the \u0026#34;openfaas\u0026#34; chart repository Update Complete. ⎈Happy Helming!⎈ In a real project, you should get the whole chart with helm pull falcosecurity/falco --untar and then configure the values.yaml. For this tutorial, will try to keep thing as easy as possible and set configs directly by passing arguments to helm install command line:\n$ helm upgrade --install falco falcosecurity/falco --namespace falco \\ --set falcosidekick.enabled=true \\ --set falcosidekick.config.fission.function=\u0026#34;falco-pod-delete\u0026#34; You should get this output:\nRelease \u0026#34;falco\u0026#34; does not exist. Installing it now. NAME: falco LAST DEPLOYED: Tue Apr 13 10:49:49 2021 NAMESPACE: falco STATUS: deployed REVISION: 1 NOTES: Falco agents are spinning up on each node in your cluster. After a few seconds, they are going to start monitoring your containers looking for security issues. No further action should be required. And you can see your new Falco and Falcosidekickpods:\n$ kubectl get pods --namespace falco NAME READY STATUS RESTARTS AGE falco-falcosidekick-f77c58899-gd467 1/1 Running 0 51s falco-falcosidekick-f77c58899-hfsjx 1/1 Running 0 51s falco-hg2wm 1/1 Running 0 51s The argument falcosidekick.enabled=true sets the following settings in Falco for you:\n--set falco.jsonOutput=true \\ --set falco.httpOutput.enabled=true \\ --set falco.httpOutput.url=http://falco-falcosidekick:2801 The arguments --set falco.jsonOutput=true --set falco.httpOutput.enabled=true --set falco.httpOutput.url=http://falco-falcosidekick:2801 are there to configure the format of events and the URL where Falco will send them. As Falco and Falcosidekick will be in the same namespace, it can directly use the name of the service (falco-falcosidekick) above Falcosidekick pods.\nWe check the logs:\n$ kubectl logs deployment/falco-falcosidekick -n falco Found 2 pods, using pod/falco-falcosidekick-f77c58899-gd467 2021/07/21 12:52:02 [INFO] : Enabled Outputs : [Fission] 2021/07/21 12:52:02 [INFO] : Falco Sidekick is up and listening on :2801 Fission is displayed as enabled output, everything is good 👍.\nInstall our Fission Function Our really basic function will receive events from Falco, thanks to Falcosidekick, check if the triggered rule is Terminal Shell in container, extract the namespace and pod name from the fields of events and delete the according pod:\nBasically, the process is:\n+----------+ +---------------+ +----------+ | Falco +-----------------\u0026gt; Falcosidekick +--------------------\u0026gt; Fission | +----^-----+ sends event +---------------+ triggers +-----+----+ | | detects a shell | | | | +----+-------+ deletes | | Pwned Pod \u0026lt;----------------------------------------------------------+ +------------+ Let's get the function and other artifacts:\n$ git clone https://github.com/fission/examples.git \u0026amp;\u0026amp; cd examples/sample/falco The function we are going to deploy basically receives events for an infected pod from the Falcosidekick and deletes it immediately. Before deploying the function we need some permissions to delete Pod. We create a ServiceAccount with rights to delete a Pod in any namespace, and we'll associate it to our function:\napiVersion: v1 kind: ServiceAccount metadata: name: falco-pod-delete namespace: fission-function --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: falco-pod-delete-cluster-role rules: - apiGroups: [\u0026#34;\u0026#34;] resources: [\u0026#34;configmaps\u0026#34;, \u0026#34;secrets\u0026#34;] verbs: [\u0026#34;get\u0026#34;] - apiGroups: [\u0026#34;\u0026#34;] resources: [\u0026#34;pods\u0026#34;] verbs: [\u0026#34;get\u0026#34;, \u0026#34;list\u0026#34;, \u0026#34;delete\u0026#34;] - apiGroups: [\u0026#34;\u0026#34;] resources: [\u0026#34;events\u0026#34;] verbs: [\u0026#34;*\u0026#34;] - apiGroups: [\u0026#34;fission.io\u0026#34;] resources: [\u0026#34;packages\u0026#34;] verbs: [\u0026#34;get\u0026#34;, \u0026#34;list\u0026#34;] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: falco-pod-delete-cluster-role-binding roleRef: kind: ClusterRole name: falco-pod-delete-cluster-role apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: falco-pod-delete namespace: fission-function Let's create the service account with:\n$ kubectl apply -f sa-falco-pod-delete.yaml The falco-pod-delete/handler.go contains our function:\npackage main import ( \u0026#34;context\u0026#34; \u0026#34;encoding/json\u0026#34; \u0026#34;io/ioutil\u0026#34; \u0026#34;log\u0026#34; \u0026#34;net/http\u0026#34; \u0026#34;time\u0026#34; metaV1 \u0026#34;k8s.io/apimachinery/pkg/apis/meta/v1\u0026#34; \u0026#34;k8s.io/client-go/kubernetes\u0026#34; \u0026#34;k8s.io/client-go/rest\u0026#34; ) var kubeClient *kubernetes.Clientset func init() { // creates the in-cluster config config, err := rest.InClusterConfig() if err != nil { panic(err.Error()) } // creates the clientset kubeClient, err = kubernetes.NewForConfig(config) if err != nil { panic(err.Error()) } } type Alert struct { Output string `json:\u0026#34;output\u0026#34;` Priority string `json:\u0026#34;priority\u0026#34;` Rule string `json:\u0026#34;rule\u0026#34;` Time time.Time `json:\u0026#34;time\u0026#34;` OutputFields struct { ContainerID string `json:\u0026#34;container.id\u0026#34;` ContainerImageRepository interface{} `json:\u0026#34;container.image.repository\u0026#34;` ContainerImageTag interface{} `json:\u0026#34;container.image.tag\u0026#34;` EvtTime int64 `json:\u0026#34;evt.time\u0026#34;` FdName string `json:\u0026#34;fd.name\u0026#34;` K8SNsName string `json:\u0026#34;k8s.ns.name\u0026#34;` K8SPodName string `json:\u0026#34;k8s.pod.name\u0026#34;` ProcCmdline string `json:\u0026#34;proc.cmdline\u0026#34;` } `json:\u0026#34;output_fields\u0026#34;` } var criticalNamespaces = []string{\u0026#34;kube-system\u0026#34;, \u0026#34;kube-public\u0026#34;, \u0026#34;kube-node-lease\u0026#34;, \u0026#34;falco\u0026#34;, \u0026#34;fission\u0026#34;, \u0026#34;fission-function\u0026#34;} func Handler(w http.ResponseWriter, r *http.Request) { var alert Alert if r.Body != nil { defer r.Body.Close() body, _ := ioutil.ReadAll(r.Body) json.Unmarshal(body, \u0026amp;alert) log.Printf(\u0026#34;\\n[ INFO ] Alert : %v\\n\u0026#34;, alert) podName := alert.OutputFields.K8SPodName namespace := alert.OutputFields.K8SNsName var critical bool for _, ns := range criticalNamespaces { if ns == namespace { critical = true break } } if !critical { _, err := kubeClient.CoreV1().Pods(namespace).Get(context.Background(), podName, metaV1.GetOptions{}) if err != nil { log.Printf(\u0026#34;\\n[ WARN ] Failed to get pod \u0026#39;%s\u0026#39; in \u0026#39;%s\u0026#39; namespace\u0026#34;, podName, namespace) return } log.Printf(\u0026#34;Deleting pod %s from namespace %s\u0026#34;, podName, namespace) err = kubeClient.CoreV1().Pods(namespace).Delete(context.Background(), podName, metaV1.DeleteOptions{}) if err != nil { log.Printf(\u0026#34;\\n[ ERROR ] Failed to delete pod: %v\u0026#34;, err) w.WriteHeader(http.StatusInternalServerError) w.Write([]byte(err.Error())) } } } w.WriteHeader(http.StatusOK) w.Write([]byte(\u0026#34;OK\u0026#34;)) } A fission function requires an environment/runtime to run. The yaml definitions for the runtime, the function and the router are available under the specs directory.\nNow, we are ready to deploy our falco-pod-delete function using the specs:\n$ fission spec apply DeployUID: edc80e3e-7d1e-448c-aba8-c8cd75b3a1eb Resources: * 1 Functions * 1 Environments * 1 Packages * 1 Http Triggers * 0 MessageQueue Triggers * 0 Time Triggers * 0 Kube Watchers * 1 ArchiveUploadSpec Validation Successful Spec doesn\u0026#39;t belong to Git Tree. 1 function created: falco-pod-delete 1 HTTPTrigger created: falco-pod-delete 1 environment created: go 1 package created: falco-pod-delete-d18f6a0b-e5a1-4275-9471-38d684ac4dfe Check if the package was built successfully for our fission function before moving to the next step:\n$ fission pkg list NAME BUILD_STATUS ENV LASTUPDATEDAT falco-pod-delete-d18f6a0b-e5a1-4275-9471-38d684ac4dfe succeeded go 21 Jul 21 08:26 IST Test our function We start by creating a dumb pod:\n$ kubectl run alpine --namespace default --image=alpine --restart=\u0026#39;Never\u0026#39; -- sh -c \u0026#34;sleep 600\u0026#34; pod/alpine created $ kubectl get pods --namespace default AME READY STATUS RESTARTS AGE alpine 1/1 Running 0 11s Let's run a shell command inside and see what happens:\n$ kubectl exec -i --tty alpine --namespace default -- sh -c \u0026#34;uptime\u0026#34; 19:27:21 up 50 min, load average: 0.11, 0.12, 0.11 As expected we got the result of our command, but, if we get the status of the pod we retrieve:\n$ kubectl get pods --namespace default NAME READY STATUS RESTARTS AGE alpine 1/1 Terminating 0 103s 💥 It has been terminated 💥\nWe can now check the logs of components.\nFor Falco:\n$ kubectl logs daemonset/falco --namespace falco .. {\u0026#34;output\u0026#34;:\u0026#34;10:36:32.750441241: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=alpine container=cbd3133ccac6 shell=sh parent=runc cmdline=sh -c uptime terminal=34816 container_id=cbd3133ccac6 image=alpine) k8s.ns=default k8s.pod=alpine container=cbd3133ccac6\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Notice\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Terminal shell in container\u0026#34;,\u0026#34;time\u0026#34;:\u0026#34;2021-07-21T10:36:32.750441241Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;container.id\u0026#34;:\u0026#34;cbd3133ccac6\u0026#34;,\u0026#34;container.image.repository\u0026#34;:\u0026#34;alpine\u0026#34;,\u0026#34;evt.time\u0026#34;:1626863792750441241,\u0026#34;k8s.ns.name\u0026#34;:\u0026#34;default\u0026#34;,\u0026#34;k8s.pod.name\u0026#34;:\u0026#34;alpine\u0026#34;,\u0026#34;proc.cmdline\u0026#34;:\u0026#34;sh -c uptime\u0026#34;,\u0026#34;proc.name\u0026#34;:\u0026#34;sh\u0026#34;,\u0026#34;proc.pname\u0026#34;:\u0026#34;runc\u0026#34;,\u0026#34;proc.tty\u0026#34;:34816,\u0026#34;user.loginuid\u0026#34;:-1,\u0026#34;user.name\u0026#34;:\u0026#34;root\u0026#34;}} {\u0026#34;output\u0026#34;:\u0026#34;10:37:09.101509967: Notice Unexpected connection to K8s API Server from container (command=fetcher -secret-dir /secrets -cfgmap-dir /configs -jaeger-collector-endpoint /userfunc k8s.ns=fission-function k8s.pod=poolmgr-go-default-516098-5bdbf8c8f5-g8gvc container=281c99ea33c2 image=fission/fetcher:1.13.1 connection=192.168.43.223:39526-\u0026gt;10.100.0.1:443) k8s.ns=fission-function k8s.pod=poolmgr-go-default-516098-5bdbf8c8f5-g8gvc container=281c99ea33c2\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Notice\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Contact K8S API Server From Container\u0026#34;,\u0026#34;time\u0026#34;:\u0026#34;2021-07-21T10:37:09.101509967Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;container.id\u0026#34;:\u0026#34;281c99ea33c2\u0026#34;,\u0026#34;container.image.repository\u0026#34;:\u0026#34;fission/fetcher\u0026#34;,\u0026#34;container.image.tag\u0026#34;:\u0026#34;1.13.1\u0026#34;,\u0026#34;evt.time\u0026#34;:1626863829101509967,\u0026#34;fd.name\u0026#34;:\u0026#34;192.168.43.223:39526-\u0026gt;10.100.0.1:443\u0026#34;,\u0026#34;k8s.ns.name\u0026#34;:\u0026#34;fission-function\u0026#34;,\u0026#34;k8s.pod.name\u0026#34;:\u0026#34;poolmgr-go-default-516098-5bdbf8c8f5-g8gvc\u0026#34;,\u0026#34;proc.cmdline\u0026#34;:\u0026#34;fetcher -secret-dir /secrets -cfgmap-dir /configs -jaeger-collector-endpoint /userfunc\u0026#34;}} .. For Falcosidekick:\n$ kubectl logs deployment/falco-falcosidekick --namespace falco .. 2021/07/21 10:37:13 [INFO] : Fission - Post OK (200) 2021/07/21 10:36:32 [INFO] : Fission - Function Response : OK 2021/07/21 10:36:32 [INFO] : Fission - Call Function \u0026#34;falco-pod-delete\u0026#34; OK .. For falco-delete-pod function:\n$ fission function logs -f --name falco-pod-delete .. [2021-07-21 10:47:27.206605532 +0000 UTC] 2021/07/21 10:47:27 Deleting pod alpine from namespace default .. Conclusion With this really simple example, we got another way to create a Response Engine with amazing pieces of software from the Open Source world. We only scratched the surface of possibilities, so don't hesitate to share with us your comments, ideas and successes.\nIf you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Integration"],"title":"Kubernetes Response Engine, Part 9: Falcosidekick + Fission","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-response-engine-part-9-fission/"},{"category":"blog","content":" This blog post is part of a series of articles about how to create a Kubernetes response engine with Falco, Falcosidekick and a FaaS.\nSee other posts:\nKubernetes Response Engine, Part 1 : Falcosidekick + Kubeless Kubernetes Response Engine, Part 2 : Falcosidekick + OpenFaas Kubernetes Response Engine, Part 3 : Falcosidekick + Knative Kubernetes Response Engine, Part 4 : Falcosidekick + Tekton Kubernetes Response Engine, Part 5 : Falcosidekick + Argo Kubernetes Response Engine, Part 6 : Falcosidekick + Cloud Run Kubernetes Response Engine, Part 7 : Falcosidekick + Cloud Functions Today, we will set up another KRE (Kubernetes Response Engine) based on Flux (version 2). If you don't know about Flux (version 2), let me explain it in a few words. Flux (version 2) is a tool for keeping Kubernetes clusters in sync with configuration sources (such as Git repositories) and automating updates to the configuration when new code is available to deploy.\nTo learn more about Flux (version 2), see Flux Documentation.\nFlux (version 2) might look like a GitOps tool. It is, in reality, another GitOps tool in that it watches Github repositories for configuration changes and keeps the current state and the desired state always in sync. It does that on top of Kubernetes by using a bunch of CRs (Custom Resources). However, unlike Knative Eventing, Tekton Triggers, and Argo Events, Flux (version 2) does not support an eventing system to forward events from one point to another.\nTo set up KRE with Flux (version 2), we will create a small project that listens to events and updates the GitHub repository, which Flux (version 2) monitors to alter the desired state. For example, get the event of a pwned pod, then change its replicas to zero within the deployment YAML file.\nThe reference architecture given below illustrates the content of this blog.\nTable of Contents\nPrerequisites Tutorial Provision local Kubernetes Cluster Install Flux V2 - GitOps Toolkit Install falco-event-listener Installing Falco and Falcosidekick Test Prerequisites minikube v1.21.0 helm v3.6.2+gee407bd kubectl v1.21.1 ko v0.8.3 flux v0.16.0 gcloud v347.0.0 Tutorial Provision local Kubernetes Cluster $ minikube config view - cpus: 3 - driver: virtualbox - memory: 8192 minikube start Install Flux V2 - GitOps Toolkit I highly recommended that you check out getting started page of Flux (version 2). It gives you detailed installation instructions for Flux (version 2).\nFor Flux (version 2) to create a GitHub repository for its resources, we must define the token and username information. Then, Flux (version 2) installed in a GitOps way, and Flux (version 2) will push its manifest to the repository.\nexport GITHUB_USER=\u0026lt;username\u0026gt; export GITHUB_TOKEN=\u0026lt;token\u0026gt; Once the necessary environment variables are defined, we can install Flux (version 2). The following command will create and push its manifests to the repository, then install Flux components.\nflux bootstrap github \\ --owner=$GITHUB_USER \\ --repository=fleet-infra \\ --branch=main \\ --path=./clusters/my-cluster \\ --personal After the installation is complete, the next step is creating the alpine GitRepository and Kustomization CRD's (Custom Resource Definitions). For more information, see components.\nApply the CRD files as follows:\n$ kubectl apply -f https://raw.githubusercontent.com/developer-guy/kubernetes-response-engine-based-on-flux-v2-gitops-toolkit/master/alpine-gitsource.yaml gitrepository.source.toolkit.fluxcd.io/alpine created $ kubectl apply -f https://raw.githubusercontent.com/developer-guy/kubernetes-response-engine-based-on-flux-v2-gitops-toolkit/master/alpine-kustomization.yaml kustomization.kustomize.toolkit.fluxcd.io/alpine created Alternatively, we can use the Flux CLI.\nTo create GitRepository:\nflux create source git alpine \\ --url https://github.com/developer-guy/desired-state-repository \\ --branch master \\ --interval 30s To create Kustomization:\nflux create kustomization alpine \\ --source alpine \\ --path \u0026#34;./\u0026#34; \\ --prune true \\ --validation client \\ --interval 5m Install falco-event-listener As the name suggests, this program will listen to an event in the form of CloudEvents. This CloudEvents forwarded from Falcosidekick, a simple daemon for enhancing available outputs for Falco. After the successful receipt of the event, falco-event-listener will update the YAML definition to scale its replicas to zero based on the pieces of information given in the event.\nIn most basic form, the architecture of the demo is:\nFalco w/HTTP --\u0026gt; Falcosidekick w/CloudEvent --\u0026gt; falco-event-listener w/HTTP --\u0026gt; GitHub\nTo learn more about CloudEvents, see cloudevents.io.\nFirst, let us clone the falco-event-listener repository.\ngit clone https://github.com/developer-guy/falco-event-listener cd falco-event-listener Before installing this project, we have to do a couple of things.\nWe have to create a GitHub PAT (Personal Access Token) to be able to update the desired state configurations which are in the GitHub repository after we detect a malicious behavior related to our pod has detected. As you can see in the above arguments, we should pass GITHUB_TOKEN as an argument to our CLI application. The best option is storing GITHUB_TOKEN in a Kubernetes Secret and using Secret as environment variables.\nkubectl create namespace falco kubectl create secret generic github-secret \\ --from-literal GITHUB_TOKEN=$GITHUB_TOKEN \\ --namespace falco You might notice that we are using some URLs (--notify-url) within the flags of the project. Let me explain that why we need it a bit. As you might know, we are trying to set up some remediation engine here, so we have to react to those events thrown by the Falcosidekick as soon as possible. We defined an interval while creating a GitRepository, which means that Flux (version 2) will wait at least that long to sync configurations, so we have to notify Flux (version 2) controllers about changes once we edited the desired state by a process whose name is falco-event-listener. To notify the Flux (version 2) controllers about changes in Git or Helm repositories, we can set up webhooks and trigger a cluster reconciliation every time a source changes. For more detail, please see. There are different kinds of webhook receivers in Flux (version 2), but we'll use the generic one in this guide.\nconst ( GenericReceiver string = \u0026#34;generic\u0026#34; GenericHMACReceiver string = \u0026#34;generic-hmac\u0026#34; GitHubReceiver string = \u0026#34;github\u0026#34; GitLabReceiver string = \u0026#34;gitlab\u0026#34; BitbucketReceiver string = \u0026#34;bitbucket\u0026#34; HarborReceiver string = \u0026#34;harbor\u0026#34; DockerHubReceiver string = \u0026#34;dockerhub\u0026#34; QuayReceiver string = \u0026#34;quay\u0026#34; GCRReceiver string = \u0026#34;gcr\u0026#34; NexusReceiver string = \u0026#34;nexus\u0026#34; ACRReceiver string = \u0026#34;acr\u0026#34; ) Let us to create a Receiver, to do that we have to a couple of things again:\n$ TOKEN=$(head -c 12 /dev/urandom | sha256sum | cut -d \u0026#39; \u0026#39; -f1) $ echo $TOKEN 0babd54d2b64d6d6fcd10a663cb6195773e968ba6642ca8c1a8a54df7b52efd0 $ kubectl -n flux-system create secret generic webhook-token \\ --from-literal=token=$TOKEN secret/webhook-token created $ cat \u0026lt;\u0026lt; EOF | kubectl apply -f - apiVersion: notification.toolkit.fluxcd.io/v1beta1 kind: Receiver metadata: name: generic-receiver namespace: flux-system spec: type: generic secretRef: name: webhook-token resources: - apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: GitRepository name: alpine namespace: flux-system EOF receiver.notification.toolkit.fluxcd.io/generic-receiver created $ cat \u0026lt;\u0026lt; EOF | kubectl apply -f - apiVersion: v1 kind: Service metadata: name: receiver namespace: flux-system spec: type: ClusterIP selector: app: notification-controller ports: - name: http port: 80 protocol: TCP targetPort: 9292 EOF This program is basically a CLI application and it uses the following arguments as:\nargs: - \u0026#34;--owner\u0026#34; - \u0026#34;developer-guy\u0026#34; # this is the owner of the desired state repository - \u0026#34;--repository\u0026#34; - \u0026#34;desired-state-repository\u0026#34; # this is the repository which we store desired state configurations - \u0026#34;--file\u0026#34; - \u0026#34;alpine.yaml\u0026#34; # this is the file that we are going to update - \u0026#34;--github-token\u0026#34; - \u0026#34;$(GITHUB_TOKEN)\u0026#34; - \u0026#34;--notify-url\u0026#34; - \u0026#34;http://receiver.flux-system/$(WEBHOOK_URL)\u0026#34; Let us run our project on the Kubernetes cluster. To do that, we'll be using the ko tool. ko, created by Google, is a simple, fast container image builder for Go applications. For more information, see the official repository of the project.\nWe'll use Container Registry as an image repository service provided by the Google Cloud to store, manage, and secure our container images. Alternatively, we could also use DockerHub, quay.io, and so on.\nexport WEBHOOK_URL=$(kubectl get receivers -n flux-system generic-receiver -ojsonpath=\u0026#39;{.status.url}\u0026#39;) export PROJECT_ID=$(gcloud config get-value project) export KO_DOCKER_REPO=gcr.io/$PROJECT_ID envsubst \u0026lt; falcoeventlistener.yaml | ko apply -f - If you are using a private container registry, don't forget to create a registry secret to pull and push images. You can follow the following guide to achieve this: https://colinwilson.uk/2020/07/09/using-google-container-registry-with-kubernetes/\nIf everything works as expected, we should see an output as given below:\n$ kubectl get pods --namespace falco NAME READY STATUS RESTARTS AGE falco-event-listener 1/1 Running 0 59s The last step we have to do is installing Falco and Falcosidekick with configuring Falcodekick to forward events to our application.\nInstalling Falco and Falcosidekick For an up-to-date and detailed guide to installing Falco and Falcosidekick, see falcosidekick).\nLet us enable CloudEvents support of Falcosidekick.\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update helm upgrade --install falco falcosecurity/falco \\ --namespace falco \\ --set falcosidekick.enabled=true \\ --set falcosidekick.webui.enabled=true \\ --set falcosidekick.config.cloudevents.address=http://falco-event-listener Verify that everything is working as expected:\n$ kubectl get pods --namespace falco NAME READY STATUS RESTARTS AGE falco-event-listener 1/1 Running 0 5m19s falco-falcosidekick-5854669c76-ddvrv 1/1 Running 0 2m16s falco-falcosidekick-5854669c76-rdlqn 1/1 Running 0 2m16s falco-falcosidekick-ui-7c5fc8dd54-q4qh9 1/1 Running 0 2m16s falco-vkl4f 1/1 Running 0 2m16s Test To test this, we have to connect a shell within the container.\nLet's list the pods that we already have.\n$ kubectl get pods NAME READY STATUS RESTARTS AGE alpine-deployment-77789455d6-m7flp 1/1 Running 15 3h6m alpine-deployment-77789455d6-v7fkw 1/1 Running 15 3h6m podinfo-6df788c7b8-gs5qb 1/1 Running 0 3h28m podinfo-6df788c7b8-sfxvd 1/1 Running 0 3h28m Now, run the following command to connect a shell.\n$ kubectl exec -ti alpine-deployment-77789455d6-m7flp -- sh -c \u0026#34;uptime\u0026#34; 19:35:58 up 3:04, load average: 3.12, 1.91, 1.22 Once you run the command above, Falco will detect that malicious behavior and send it to the Falcosidekick via HTTP.\nYou should see an output in the Falco logs as given below:\n{\u0026#34;output\u0026#34;:\u0026#34;19:35:58.532086161: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=alpine-deployment-77789455d6-m7flp container=788861c3cf83 shell=sh parent=runc cmdline=sh -c uptime terminal=34816 container_id=788861c3cf83 image=alpine) k8s.ns=default k8s.pod=alpine-deployment-77789455d6-m7flp container=788861c3cf83\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Notice\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Terminal shell in container\u0026#34;,\u0026#34;time\u0026#34;:\u0026#34;2021-06-13T19:35:58.532086161Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;container.id\u0026#34;:\u0026#34;788861c3cf83\u0026#34;,\u0026#34;container.image.repository\u0026#34;:\u0026#34;alpine\u0026#34;,\u0026#34;evt.time\u0026#34;:1623612958532086161,\u0026#34;k8s.ns.name\u0026#34;:\u0026#34;default\u0026#34;,\u0026#34;k8s.pod.name\u0026#34;:\u0026#34;alpine-deployment-77789455d6-m7flp\u0026#34;,\u0026#34;proc.cmdline\u0026#34;:\u0026#34;sh -c uptime\u0026#34;,\u0026#34;proc.name\u0026#34;:\u0026#34;sh\u0026#34;,\u0026#34;proc.pname\u0026#34;:\u0026#34;runc\u0026#34;,\u0026#34;proc.tty\u0026#34;:34816,\u0026#34;user.loginuid\u0026#34;:-1,\u0026#34;user.name\u0026#34;:\u0026#34;root\u0026#34;}} and the similar output below in the Falcosidekick logs:\nfalco-falcosidekick-5854669c76-ddvrv falcosidekick 2021/06/13 19:51:45 [INFO] : CloudEvents - Send OK and the similar output below in the falco-event-listener logs:\nfalco-event-listener falco-event-listener 2021/06/13 19:35:59 resp.Status=200 OK falco-event-listener falco-event-listener 2021/06/13 19:35:59 resp.StatusCode=200 falco-event-listener falco-event-listener 2021/06/13 19:35:59 [Terminal shell in container] scaled down to zero alpine-deployment-77789455d6-m7flp from default because 19:35:58.532086161: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=alpine-deployment-77789455d6-m7flp container=788861c3cf83 shell=sh parent=runc cmdline=sh -c uptime terminal=34816 container_id=788861c3cf83 image=alpine) k8s.ns=default k8s.pod=alpine-deployment-77789455d6-m7flp container=788861c3cf83 You should also notice that a new commit is available in the desired-state-repository as given below:\nAfter the commit, Flux (version 2) will detect the change and sync the current state of the cluster with the desired state in the GitHub repository so that Flux (version 2) will terminate the alpine deployment pods.\n$ kubectl get pods -l app=alpine No resources found in default namespace. ","summary":"","tags":["Falcosidekick","Integration"],"title":"Kubernetes Response Engine, Part 8: Falcosidekick + Flux v2","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-response-engine-part-8-fluxv2/"},{"category":"blog","content":"Introduction In the previous blog post, we had talked about the Audit Logs in more detail, this post is a continuation of the previous blog post, so I suggest you take a look at the previous blog post before continuing reading. The only difference in this blog post is that this time we will use Log Backend mode, which is one of the Audit Backends that kube-apiserver supports, then we will use some kind of log collector project which is FluentBit in this case to gather these audit logs and forward them to some HTTP endpoint. You might be thinking why this kind of architecture can be more useful, the answer is that in the previous blog post we used Webhook Backend mode, so we could send the audit logs to one location only. But with using Log Backend mode and FluentBit, we are now able to send audit logs to different locations, so we are now more flexible in this regard.\nHere is the high-level overview architecture that shows what we want to achieve at the end of the day:\nPrerequisites We need tools with the following minimum versions to achieve this demo:\nminikube v1.22.0 kubectl v1.21.2 helm v3.6.2+gee407bd Tutorial Provision local Kubernetes Cluster There are various ways to provision a local Kubernetes cluster such as KinD, k3s, k0s, Minikube etc. We are going to use Minikube this time in this walkthrough.\nThere is a detailed guide about configuring Audit Logging in minikube, if you want to learn more about it, please see.\nLet's get provision a local Kubernetes cluster:\n$ minikube config view - cpus: 3 - driver: virtualbox - memory: 8192 $ minikube start 😄 minikube v1.22.0 on Darwin 10.15.7 ✨ Using the virtualbox driver based on existing profile 👍 Starting control plane node minikube in cluster minikube 🔄 Restarting existing virtualbox VM for \u0026#34;minikube\u0026#34; ... 🐳 Preparing Kubernetes v1.21.2 on Docker 20.10.6 ... 🔎 Verifying Kubernetes components... ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5 🌟 Enabled addons: storage-provisioner 🏄 Done! kubectl is now configured to use \u0026#34;minikube\u0026#34; cluster and \u0026#34;default\u0026#34; namespace by default Enable Kubernetes Audit Logging Let's connect to the Minikube instance, which runs in VM, and download the Audit Policy file. This file is kind of a filter to decide what should be in the Audit Logs. This Audit Log file can grow very quickly and cause some performance issues if we didn't filter anything.\nThis is not the recommended Audit Policy file, this is just an example, it would be better to prepare your Audit Policy file that is suitable for your needs.\n$ minikube ssh _ _ ( ) ( ) ___ ___ (_) ___ (_)| |/\u0026#39;) _ _ | |_ __ /\u0026#39; _ ` _ `\\| |/\u0026#39; _ `\\| || , \u0026lt; ( ) ( )| \u0026#39;_`\\ /\u0026#39;__`\\ | ( ) ( ) || || ( ) || || |\\`\\ | (_) || |_) )( ___/ (_) (_) (_)(_)(_) (_)(_)(_) (_)`\\___/\u0026#39;(_,__/\u0026#39;`\\____) $ sudo mkdir -p /etc/kubernetes/audit $ sudo curl -sLo /etc/kubernetes/audit/audit-policy.yaml \\ https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/audit/audit-policy.yaml Let's edit the kube-apiserver, which is deployed as static Pod with the necessary flags and volumes to enable the Audit Logging.\n$ sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml # Update Result spec.containers.kube-apiserver.command + two list entries added: - --audit-policy-file=/etc/kubernetes/audit/audit-policy.yaml - --audit-log-path=/var/log/kubernetes/kube-apiserver-audit.log spec.containers.kube-apiserver.volumeMounts + two list entries added: - name: audit-log │ mountPath: /var/log/kubernetes/kube-apiserver-audit.log │ readOnly: false - name: audit-policy │ mountPath: /etc/kubernetes/audit/audit-policy.yaml │ readOnly: true spec.volumes + two list entries added: - name: audit-log │ hostPath: │ │ type: FileOrCreate │ │ path: /var/log/kubernetes/kube-apiserver-audit.log - name: audit-policy │ hostPath: │ │ type: File │ │ path: /etc/kubernetes/audit/audit-policy.yaml Once you updated the manifest file, the kube-apiserver can't be reachable for a while, so please keep trying until the kube-apiserver becoming healthy.\nThe audit log file should be generated when the kube-apiserver becomes healthy, so please be sure about this before moving into the next phase.\n$ minikube ssh _ _ ( ) ( ) ___ ___ (_) ___ (_)| |/\u0026#39;) _ _ | |_ __ /\u0026#39; _ ` _ `\\| |/\u0026#39; _ `\\| || , \u0026lt; ( ) ( )| \u0026#39;_`\\ /\u0026#39;__`\\ | ( ) ( ) || || ( ) || || |\\`\\ | (_) || |_) )( ___/ (_) (_) (_)(_)(_) (_)(_)(_) (_)`\\___/\u0026#39;(_,__/\u0026#39;`\\____) $ ls -latr /var/log/kubernetes/ total 4868 drwxr-xr-x 6 root root 4096 Jul 21 17:37 .. drwxr-xr-x 2 root root 4096 Jul 21 17:37 . -rw-r--r-- 1 root root 4973184 Jul 21 18:39 kube-apiserver-audit.log Install Falco and Falcosidekick with Auditing Feature Enabled We'll use Helm to install the Falco, so there is an option that we can enable or disable the audit log feature called auditLog.enabled, once we set the value of the option as true, the embedded webserver will be started within the Falco to consume audit events from the port 8765 and behind k8s-audit endpoint.\nFirstly, we'll create the namespace that will host both Falco and Falcosidekick:\n$ kubectl create namespace falco namespace/falco created We add the helm repo:\n$ helm repo add falcosecurity https://falcosecurity.github.io/charts \u0026#34;falcosecurity\u0026#34; has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the \u0026#34;falcosecurity\u0026#34; chart repository In a real project, you should get the whole chart with helm pull falcosecurity/falco --untar and then configure the values.yaml. For this tutorial, will try to keep thing as easy as possible and set configs directly by passing arguments to helm install command line:\n$ helm upgrade --install falco falcosecurity/falco --namespace falco \\ --set falcosidekick.enabled=true \\ --set falcosidekick.webui.enabled=true \\ --set auditLog.enabled=true You should get this output:\nRelease \u0026#34;falco\u0026#34; does not exist. Installing it now. NAME: falco LAST DEPLOYED: Tue Apr 13 10:49:49 2021 NAMESPACE: falco STATUS: deployed REVISION: 1 NOTES: Falco agents are spinning up on each node in your cluster. After a few seconds, they are going to start monitoring your containers looking for security issues. No further action should be required. And you can see your new Falco and Falcosidekick pods:\n$ kubectl get pods --namespace falco NAME READY STATUS RESTARTS AGE falco-falcosidekick-76f5885f7f-956vj 1/1 Running 0 4m27s falco-falcosidekick-76f5885f7f-tmff6 1/1 Running 0 4m27s falco-falcosidekick-ui-5b64749bc8-k8v4p 1/1 Running 0 4m27s falco-h4qvx 1/1 Running 0 4m27s Check your services within the namespace falco, and you should see that Falco service has 8765 port, let's verify that.\n$ kubectl get services --namespace falco NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE falco ClusterIP 10.96.156.167 \u0026lt;none\u0026gt; 8765/TCP 4m40s falco-falcosidekick ClusterIP 10.105.37.184 \u0026lt;none\u0026gt; 2801/TCP 4m40s falco-falcosidekick-ui ClusterIP 10.111.57.54 \u0026lt;none\u0026gt; 2802/TCP 4m40s The argument falcosidekick.enabled=true sets the following settings in Falco for you:\n--set falco.jsonOutput=true \\ --set falco.httpOutput.enabled=true \\ --set falco.httpOutput.url=http://falco-falcosidekick:2801 The arguments --set falco.jsonOutput=true --set falco.httpOutput.enabled=true --set falco.httpOutput.url=http://falco-falcosidekick:2801 are there to configure the format of events and the URL where Falco will send them. As Falco and Falcosidekick will be in the same namespace, it can directly use the name of the service (falco-falcosidekick) above Falcosidekick pods.\nWe check the logs:\n$ kubectl logs deployment/falco-falcosidekick --namespace falco Found 2 pods, using pod/falco-falcosidekick-76f5885f7f-tmff6 2021/05/22 15:46:58 [INFO] : Enabled Outputs : [WebUI] 2021/05/22 15:46:58 [INFO] : Falco Sidekick is up and listening on :2801 WebUI is displayed as enabled output, everything is good 👍.\nDeploy FluentBit In order to deploy FluentBit, we're going to use its Helm chart with our own configurations.\nIf you want to get more detail about the Helm chart of the FluentBit, please see.\n$ cat \u0026lt;\u0026lt; EOF | tee values-override.yaml config: inputs: | [INPUT] Name tail Alias kube_audit Tag kube_audit Buffer_Chunk_Size 512k Buffer_Max_Size 5m Path /var/log/kubernetes/kube-apiserver-audit.log Parser json DB /var/log/kube_audit_log.db Mem_Buf_Limit 128MB Skip_Long_Lines On Refresh_Interval 10 outputs: | [OUTPUT] Name http Alias kube_audit_to_falco Match kube_audit Host falco.falco Port 8765 URI /k8s-audit Format json EOF $ kubectl create namespace logging namespace/logging created $ helm upgrade --install fluent-bit fluent/fluent-bit \\ -f values-override.yaml \\ -n logging Release \u0026#34;fluent-bit\u0026#34; has been upgraded. Happy Helming! NAME: fluent-bit LAST DEPLOYED: Wed Jul 21 22:59:25 2021 NAMESPACE: logging STATUS: deployed REVISION: 1 NOTES: Get Fluent Bit build information by running these commands: export POD_NAME=$(kubectl get pods --namespace logging -l \u0026#34;app.kubernetes.io/name=fluent-bit,app.kubernetes.io/instance=fluent-bit\u0026#34; -o jsonpath=\u0026#34;{.items[0].metadata.name}\u0026#34;) echo \u0026#34;curl http://127.0.0.1:2020 for Fluent Bit build information\u0026#34; kubectl --namespace logging port-forward $POD_NAME 2020:2020 Now we are ready to test everything.\nTest There is a rule called Create/Modify Configmap With Private Credentials in Falco for detecting ConfigMaps that contains private credentials from Kubernetes Audit Logs. You can see the details of the rule from this link. To test this, we should create a ConfigMap that contains private credentials.\nFirst, use kubectl port-forward to access the Falco Sidekick UI:\n$ kubectl --namespace=falco port-forward svc/falco-falcosidekick-ui 2802 Forwarding from 127.0.0.1:2802 -\u0026gt; 2802 Forwarding from [::1]:2802 -\u0026gt; 2802 Open http://localhost:2802/ui/ to load the UI (omitting the /ui/ portion of the URL will result in an error)\nNow, let's create the ConfigMap.\n$ kubectl create configmap aws-creds \\ --from-literal aws_access_key_id=AKES20LNOA configmap/aws-creds created As soon as you created the ConfigMap, the Audit Log will be generated, then FluentBit will gather the audit log and send it to Falco. In turn, Falco will detect the malicious behavior from the audit logs and send an alert to the Falcosidekick. Finally, Falcosidekick forwards the alert to the Web UI. So, you should see similar screens like the following:\nConclusion With this really simple example, we only want to show how FluentBit can be useful for us to implement this kind of architecture.\nIf you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":null,"title":"Detect Malicious Behaviour on Kubernetes API Server through gathering Audit Logs by using FluentBit - Part 2","url":"https://v0-43--falcosecurity.netlify.app/blog/detect-malicious-behaviour-on-kubernetes-api-server-through-gathering-audit-logs-by-using-fluentbit-part-2/"},{"category":"blog","content":" This blog post is part of a series of articles about how to create a Kubernetes response engine with Falco, Falcosidekick and a FaaS.\nSee other posts:\nKubernetes Response Engine, Part 1 : Falcosidekick + Kubeless Kubernetes Response Engine, Part 2 : Falcosidekick + OpenFaas Kubernetes Response Engine, Part 3 : Falcosidekick + Knative Kubernetes Response Engine, Part 4 : Falcosidekick + Tekton Kubernetes Response Engine, Part 5 : Falcosidekick + Argo Kubernetes Response Engine, Part 6 : Falcosidekick + Cloud Run Earlier in this series, we have seen how to use Argo, Tekton, and Knative to trigger a resource after getting input from Falcosidekick. Recently, Falcosidekick received a new output type support for Cloud Functions.\nIn this part, let us learn how we can use Falcosidekick and Cloud Functions to detect and delete a compromised pod.\nWe will not go through what Cloud Functions is in-depth, however, you can always find a good overview about it in the official documentation.\nHere is the high-level overview architecture that shows what we want to achieve at the end of the day:\nYou can find all the related code and resources in this repository.\nPrerequisites gcloud 342.0.0 kubectl 1.20.5 Tutorial Provision Google Kubernetes Engine (GKE) Cluster As the blog title said already, we need to create a GKE cluster with workload identity enabled:\n$ GOOGLE_PROJECT_ID=$(gcloud config get-value project) $ CLUSTER_NAME=falco-falcosidekick-demo $ gcloud container clusters create $CLUSTER_NAME --workload-pool ${GOOGLE_PROJECT_ID}.svc.id.goog $ gcloud container clusters get-credentials $CLUSTER_NAME Configure IAM Service Accounts We need to create a new Service Account for target $GOOGLE_PROJECT_ID using IAM Binding policies to get access our Cloud Function:\n$ SA_ACCOUNT=falco-falcosidekick-sa $ gcloud iam service-accounts create $SA_ACCOUNT $ gcloud projects add-iam-policy-binding ${GOOGLE_PROJECT_ID} \\ --member=\u0026#34;serviceAccount:${SA_ACCOUNT}@${GOOGLE_PROJECT_ID}.iam.gserviceaccount.com\u0026#34; \\ --role=\u0026#34;roles/cloudfunctions.developer\u0026#34; $ gcloud projects add-iam-policy-binding ${GOOGLE_PROJECT_ID} \\ --member=\u0026#34;serviceAccount:${SA_ACCOUNT}@${GOOGLE_PROJECT_ID}.iam.gserviceaccount.com\u0026#34; \\ --role=\u0026#34;roles/cloudfunctions.invoker\u0026#34; In the beginning, we already enabled WorkloadIdentity feature for our GKE Cluster by setting --workload-pool flag. What we need to do here is to add a iam.workloadIdentityUser role for the given Service Account.\n$ gcloud iam service-accounts add-iam-policy-binding \\ --role roles/iam.workloadIdentityUser \\ --member \u0026#34;serviceAccount:${GOOGLE_PROJECT_ID}.svc.id.goog[${FALCO_NAMESPACE}/falco-falcosidekick]\u0026#34; \\ ${SA_ACCOUNT}@${GOOGLE_PROJECT_ID}.iam.gserviceaccount.com We need to annotate the falco-falcosidekick resource. So it can grant access for our Cluster. Set up the Falcosidekick SA to impersonate a GCP SA:\n$ kubectl annotate serviceaccount \\ --namespace $FALCO_NAMESPACE \\ falco-falcosidekick \\ iam.gke.io/gcp-service-account=${SA_ACCOUNT}@${GOOGLE_PROJECT_ID}.iam.gserviceaccount.com Create Necessary Cluster Role To limit function role access in the particular cluster, ensure that only SA has limited permissions within a particular namespace by using Role Bindings.\n$ kubectl create serviceaccount pod-destroyer $ kubectl create clusterrole pod-destroyer --verb=delete --resource=pod # give only pod resource access for delete op $ kubectl create clusterrolebinding pod-destroyer --clusterrole pod-destroyer --serviceaccount default:pod-destroyer To obtain the Token from secret, we need to get pod-deleter ServiceAccount resource first:\n$ POD_DESTROYER_TOKEN=$(kubectl get secrets $(kubectl get serviceaccounts pod-deleter -o json \\ | jq -r \u0026#39;.secrets[0].name\u0026#39;) -o json \\ | jq -r \u0026#39;.data.token\u0026#39; \\ | base64 -D) Add the pod-destroyer user to your KUBECONFIG:\n# Generate your KUBECONFIG $ kubectl config view --minify --flatten \u0026gt; kubeconfig_pod-destroyer.yaml # Set the token at the end of yaml $ cat \u0026lt;\u0026lt; EOF \u0026gt;\u0026gt; kubeconfig_pod-destroyer.yaml users: - name: user.name user: token: $POD_DESTROYER_TOKEN We can test it with auth can-i to check if roles are set correctly\n$ kubectl auth can-i list deployments # no $ kubectl auth can-i delete pod # yes $ kubectl access-matrix # github.com/corneliusweig/rakkess Create Secret Manager The main reason Secret Manager get involved our architecture is because we had to find a way out to initialize our kubeclient in our function by getting pod-destroyer's KUBECONFIG.\nWe need to create a new secrets IAM policy for the SA member to enable Managing Secrets:\n$ gcloud secrets add-iam-policy-binding pod-destroyer \\ --role roles/secretmanager.secretAccessor \\ --member serviceAccount:$SA_ACCOUNT@$GOOLE_PROJECT_ID.iam.gserviceaccount.com Create a new secret, called pod-destroyer:\n$ gcloud secrets create pod-destroyer --replication-policy=\u0026#34;automatic\u0026#34; Push the our generated kubeconfig_pod-destroyer.yaml file as a new version:\n$ gcloud secrets versions add pod-destroyer --data-file=kubeconfig_pod-destroyer.yaml Finally, we are ready to deploy our Cloud Run function!\nDeploy Google Cloud Function In this demonstration our function will simply delete the pwned Pod, as we already pointed it out in the architecture diagram.\nThe Go code package kill_the_pwned_pod import ( secretmanager \u0026#34;cloud.google.com/go/secretmanager/apiv1\u0026#34; \u0026#34;context\u0026#34; \u0026#34;encoding/json\u0026#34; \u0026#34;fmt\u0026#34; secretmanagerpb \u0026#34;google.golang.org/genproto/googleapis/cloud/secretmanager/v1\u0026#34; \u0026#34;io/ioutil\u0026#34; metaV1 \u0026#34;k8s.io/apimachinery/pkg/apis/meta/v1\u0026#34; \u0026#34;k8s.io/client-go/kubernetes\u0026#34; \u0026#34;k8s.io/client-go/tools/clientcmd\u0026#34; \u0026#34;net/http\u0026#34; \u0026#34;os\u0026#34; \u0026#34;time\u0026#34; ) // Alert falco data structure type Alert struct { Output string `json:\u0026#34;output\u0026#34;` Priority string `json:\u0026#34;priority\u0026#34;` Rule string `json:\u0026#34;rule\u0026#34;` Time time.Time `json:\u0026#34;time\u0026#34;` OutputFields struct { ContainerID string `json:\u0026#34;container.id\u0026#34;` ContainerImageRepository interface{} `json:\u0026#34;container.image.repository\u0026#34;` ContainerImageTag interface{} `json:\u0026#34;container.image.tag\u0026#34;` EvtTime int64 `json:\u0026#34;evt.time\u0026#34;` FdName string `json:\u0026#34;fd.name\u0026#34;` K8SNsName string `json:\u0026#34;k8s.ns.name\u0026#34;` K8SPodName string `json:\u0026#34;k8s.pod.name\u0026#34;` ProcCmdline string `json:\u0026#34;proc.cmdline\u0026#34;` } `json:\u0026#34;output_fields\u0026#34;` } var op Operation type Operation struct { clientSet *kubernetes.Clientset } // init initializes new Kubernetes ClientSet with given config func init() { // The resource name of the KUBECONFIG_SECRET_NAME in the format // `projects/*/secrets/*/versions/*` resource := os.Getenv(\u0026#34;KUBECONFIG_SECRET_NAME\u0026#34;) if len(resource) == 0 { panic(fmt.Errorf(\u0026#34;$KUBECONFIG_SECRET_NAME env variable did not set\u0026#34;)) } secret, err := GetSecret(resource) if err != nil { panic(fmt.Errorf(\u0026#34;get secret: %q\u0026#34;, err)) } kubeCfg, err := clientcmd.NewClientConfigFromBytes(secret) if err != nil { panic(fmt.Errorf(\u0026#34;new client config: %q\u0026#34;, err)) } restCfg, err := kubeCfg.ClientConfig() if err != nil { panic(fmt.Errorf(\u0026#34;client config: %q\u0026#34;, err)) } cs, err := kubernetes.NewForConfig(restCfg) if err != nil { panic(fmt.Errorf(\u0026#34;unable to initialize config: %q\u0026#34;, err)) } op = Operation{clientSet: cs} } // KillThePwnedPod will executed for each Falco event func KillThePwnedPod(w http.ResponseWriter, r *http.Request) { body, err := ioutil.ReadAll(r.Body) if err != nil { http.Error(w, \u0026#34;cannot read body\u0026#34;, http.StatusBadRequest) return } var event Alert err = json.Unmarshal(body, \u0026amp;event) if err != nil { http.Error(w, \u0026#34;cannot parse body\u0026#34;, http.StatusBadRequest) return } err = op.PodDestroy(event.OutputFields.K8SPodName, event.OutputFields.K8SNsName) if err != nil { http.Error(w, fmt.Sprintf(\u0026#34;cannot delete pod: %q\u0026#34;, err), http.StatusInternalServerError) return } w.WriteHeader(http.StatusOK) } // PodDestroy destroys the given pod name in the given namespace func (d *Operation) PodDestroy(name, namespace string) error { err := d.clientSet.CoreV1().Pods(namespace).Delete(context.TODO(), name, metaV1.DeleteOptions{}) if err != nil { return fmt.Errorf(\u0026#34;unable to delete pod %s: %q\u0026#34;, name, err) } return nil } // GetSecret returns the secret data. func GetSecret(name string) ([]byte, error) { ctx := context.Background() client, err := secretmanager.NewClient(ctx) if err != nil { return nil, fmt.Errorf(\u0026#34;failed to create secretmanager client: %v\u0026#34;, err) } defer client.Close() result, err := client.AccessSecretVersion(ctx, \u0026amp;secretmanagerpb.AccessSecretVersionRequest{ Name: name, }) if err != nil { return nil, fmt.Errorf(\u0026#34;failed to access secret version: %v\u0026#34;, err) } return result.Payload.Data, nil } If you rather see it in GitHub.\n$ git clone https://github.com/Dentrax/k8s-response-engine-gke-functions.git $ cd kubernetes-response-engine-based-on-gke-and-gcloudfunctions ... We need to pass extra --service-account flag in order to get access to Secret Manager.\nDeploy the function:\n$ FUNCTION_NAME=KillThePwnedPod $ gcloud functions deploy $FUNCTION_NAME \\ --runtime go113 --trigger-http \\ --service-account $SA_ACCOUNT@$GOOLE_PROJECT_ID.iam.gserviceaccount.com Allow unauthenticated invocations of new function [KillThePwnedPod]? (y/N)? N ... Now, get the name of the function:\n$ CLOUD_FUNCTION_NAME=$(gcloud functions describe --format=json $FUNCTION_NAME | jq -r \u0026#39;.name\u0026#39;) Install Falco + Falcosidekick It is time to install Falco, Falcosidekick with Cloud Function output type enabled:\n$ export FALCO_NAMESPACE=falco $ kubectl create namespace $FALCO_NAMESPACE $ helm upgrade --install falco falcosecurity/falco \\ --namespace $FALCO_NAMESPACE \\ --set ebpf.enabled=true \\ --set falcosidekick.enabled=true \\ --set falcosidekick.config.gcp.cloudfunctions.name=${CLOUD_FUNCTION_NAME} \\ --set falcosidekick.webui.enabled=true Test Try to run a busybox image and execute a command:\n$ kubectl run busybox --image=busybox --restart=\u0026#39;Never\u0026#39; -- sh -c \u0026#34;sleep 600\u0026#34; Try to exec into:\n$ kubectl exec -it busybox -- sh -c \u0026#34;uptime\u0026#34; We can check the logs of the Falco, and Falcosidekick to see what happened:\nFor Falcosidekick:\n$ kubectl logs deployment/falco-falcosidekick --namespace falco 2021/06/14 21:01:24 [INFO] : GCPCloudFunctions - Call Cloud Function OK .. Conclusion We got another way to create a Response Engine with amazing pieces of software from Open Source world. Of course, it's just the beginning, feel free to share your functions and workflows with the community for starting the creation of a true library of remediation methods.\nIf you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Integration"],"title":"Kubernetes Response Engine, Part 7: Falcosidekick + Cloud Functions","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-response-engine-part-7-cloud-functions/"},{"category":"blog","content":" This blog post is part of a series of articles about how to create a Kubernetes response engine with Falco, Falcosidekick and a FaaS.\nSee other posts:\nKubernetes Response Engine, Part 1 : Falcosidekick + Kubeless Kubernetes Response Engine, Part 2 : Falcosidekick + OpenFaas Kubernetes Response Engine, Part 3 : Falcosidekick + Knative Kubernetes Response Engine, Part 4 : Falcosidekick + Tekton Kubernetes Response Engine, Part 5 : Falcosidekick + Argo Kubernetes Response Engine, Part 7: Falcosidekick + Cloud Functions Recently, we added two new output-type support to Falcosidekick, and they are Cloud Functions, and Cloud Run. This blog post will discuss how to set up Kubernetes Response Engine on GKE (Google Kubernetes Engine) by using Cloud Run.\nLet's start by explaining a little bit about Cloud Run. Cloud Run is a managed compute platform that enables you to run containers that are invocable via requests or events. Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most — building great applications.\nFor more information, see Cloud Run.\nGiven below is a reference architecture of what's being explained in this blog.\nThis demo might be useful for Google Cloud users who might already be using GKE with Falco to protect container runtime against malicious behaviors, and wants to take any action for them with Cloud Run.\nTable of Contents\nPrerequisites Tutorial Provision GKE (Google Kubernetes Engine) Cluster Deploy Cloud Run Function Install Falco + Falcosidekick Test Conclusion Prerequisites gcloud 342.0.0 ko 0.8.3 Tutorial Provision GKE (Google Kubernetes Engine) Cluster First, let us create a GKE cluster.\n$ GKE_CLUSTER_NAME=cloud-run-demo $ gcloud container clusters create $GKE_CLUSTER_NAME To learn more about the setup GKE Cluster, see quickstart guide.\nDeploy Cloud Run Function Once GKE is set up, we are ready to deploy Cloud Run. But before doing that, let us examine the responsibility of the Cloud Run function. As you can see in the reference architecture, this function will delete the pwned pods. To be able to do that, Cloud Run should be given appropriate permissions.\nThere are two approaches to obtain these permissions.\nThe first approach is creating a Kubernetes Service Account, an appropriate Role with granted permissions to delete pod resource, and a RoleBinding to bind Role to Service Account. Then create the kubeconfig file, package it up with the function code while deploying the Cloud Run function, and use this file to create a Kubernetes client. To learn more about the kubeconfig files, see kubeconfig.\nThe second approach is producing a valid ~/.kube/config with a library called google.golang.org/api/ within the function code. We are doing this because the representation of the valid ~/.kube/config file is clientcmd/api/Config in Go. We'll go with the second approach in this demo. Thanks to Scott Blum and his detailed blog post on this topic. I highly recommend that you check that out.\nLet's deploy the function. If you want to take a look at the function code, see the repository.\nNote that we're going to use the ko tool to build and push our container image which is created by Google. ko is a simple and fast container image builder for Go applications.\nTo learn more, see the official repository of the project.\nWe are also going to use Container Registry as an image repository service provided by the Google Cloud to store, manage, and secure your Docker container images. Alternatively, you can also use DockerHub, quay.io, etc.\n$ git clone https://github.com/developer-guy/kubernetes-response-engine-based-on-gke-and-cloud-run.git $ cd kubernetes-response-engine-based-on-gke-and-cloud-run $ GKE_CLUSTER_NAME=$(kubectl config view --minify -o jsonpath=\u0026#39;{.clusters[].name}{\u0026#34;\\n\u0026#34;}\u0026#39;) $ PROJECT_ID=$(gcloud config get-value project) $ FUNCTION_NAME=pod-deleter $ export KO_DOCKER_REPO=gcr.io/$PROJECT_ID # Please, change this variable if you are not using Container Registry. $ gcloud config set run/region us-west1 $ gcloud config set run/platform managed $ gcloud run deploy $FUNCTION_NAME --image=$(ko publish .) \\ --set-env-vars GKE_CLUSTER_NAME=$GKE_CLUSTER_NAME \\ --set-env-vars PROJECT_ID=$PROJECT_ID ... Allow unauthenticated invocations to [pod-deleter] (y/N)? N Deploying container to Cloud Run service [pod-deleter] in project [developerguy-311909] region [us-west1] ✓ Deploying... Done. ✓ Creating Revision... ✓ Routing traffic... Done. Service [pod-deleter] revision [pod-deleter-00002-cej] has been deployed and is serving 100 percent of traffic. Service URL: https://pod-deleter-uoz6q2wria-uw.a.run.app Install Falco + Falcosidekick Now, it is time to set up Falco, Falcosidekick with the Cloud Run output type enabled.\n$ kubectl create namespace falco $ helm repo add falcosecurity https://falcosecurity.github.io/charts $ helm repo update $ helm install falco falcosecurity/falco --namespace falco \\ --set ebpf.enabled=true \\ --set falcosidekick.enabled=true \\ --set falcosidekick.webui.enabled=true \\ --set falcosidekick.config.gcp.cloudrun.endpoint=$(gcloud run services list --format json | jq -r \u0026#34;.[] | select(.metadata.name==\\\u0026#34;$FUNCTION_NAME\\\u0026#34;) | .status.address.url\u0026#34;) \\ --set falcosidekick.config.gcp.cloudrun.jwt=$(gcloud auth print-identity-token) Check the logs to see if Cloud Run output enabled for Falcosidekick.\n$ kubectl logs -f falco-falcosidekick-7cd7bc6859-2nd9t --namespace falco falco-falcosidekick-7cd7bc6859-2nd9t falcosidekick 2021/06/07 16:03:14 [INFO] : Enabled Outputs : [GCPCloudRun WebUI] falco-falcosidekick-7cd7bc6859-2nd9t falcosidekick 2021/06/07 16:03:14 [INFO] : Falco Sidekick is up and listening on :2801 ... If you see the GCPCloudRun in the list of enabled outputs, you can confirm that everything is working as expected 👍.\nTest Let us start by creating a test pod:\n$ kubectl run alpine --namespace default --image=alpine --restart=\u0026#39;Never\u0026#39; -- sh -c \u0026#34;sleep 600\u0026#34; pod/alpine created $ kubectl get pods --namespace default AME READY STATUS RESTARTS AGE alpine 1/1 Running 0 11s Let's run a shell command inside and see what happens:\n$ kubectl exec -i --tty alpine --namespace default -- sh -c \u0026#34;uptime\u0026#34; 19:27:21 up 50 min, load average: 0.11, 0.12, 0.11 As expected the command returned the output. However, the status of the pod we retrieved is Terminating as follows:\n$ kubectl get pods --namespace default NAME READY STATUS RESTARTS AGE alpine 1/1 Terminating 0 103s To investigate further, check the logs of the Cloud Run function from the Google Cloud Console:\nLet us check the logs of Falco and Falcosidekick to see what happened.\n$ kubectl logs daemonset/falco --namespace falco .. {\u0026#34;output\u0026#34;:\u0026#34;19:27:21.002873265: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=alpine container=97c9868ea832 shell=sh parent=runc cmdline=sh -c uptime terminal=34816 container_id=97c9868ea832 image=alpine) k8s.ns=default k8s.pod=alpine container=97c9868ea832\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Notice\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Terminal shell in container\u0026#34;,\u0026#34;time\u0026#34;:\u0026#34;2021-04-10T19:27:21.002873265Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;container.id\u0026#34;:\u0026#34;97c9868ea832\u0026#34;,\u0026#34;container.image.repository\u0026#34;:\u0026#34;alpine\u0026#34;,\u0026#34;evt.time\u0026#34;:1618082841002873265,\u0026#34;k8s.ns.name\u0026#34;:\u0026#34;default\u0026#34;,\u0026#34;k8s.pod.name\u0026#34;:\u0026#34;alpine\u0026#34;,\u0026#34;proc.cmdline\u0026#34;:\u0026#34;sh -c uptime\u0026#34;,\u0026#34;proc.name\u0026#34;:\u0026#34;sh\u0026#34;,\u0026#34;proc.pname\u0026#34;:\u0026#34;runc\u0026#34;,\u0026#34;proc.tty\u0026#34;:34816,\u0026#34;user.loginuid\u0026#34;:-1,\u0026#34;user.name\u0026#34;:\u0026#34;root\u0026#34;}} ... For Falcosidekick:\n$ kubectl logs deployment/falco-falcosidekick --namespace falco 2021/06/07 16:03:15 [INFO] : GCPCloudRun - Post OK (200) 2021/06/07 16:03:15 [INFO] : GCPCloudRun - Function Response : OK .. Conclusion We got another way to create a Response Engine with amazing pieces of software from the Open Source world. Of course, it's just the beginning, feel free to share your functions and workflows with the community for creating a library of remediation methods.\nIf you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Integration"],"title":"Kubernetes Response Engine, Part 6: Falcosidekick + Cloud Run","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-response-engine-part-6-cloud-run/"},{"category":"blog","content":"Today we announce the summer release of Falco 0.29.0 🌱\nThis version brings a lot of new features and fixes!\nNovelties 🆕 Let's now review some of the new things Falco 0.29.0 brings.\nNew libraries repository! As per this proposal - and as many of you probably already know - the repo falcosecurity/libs is the new home for libscap, libsinsp, and the Falco drivers.\nWith this release, also the last missing piece of the libs contribution is done: the building system is now updated to point to the new location and also the driver version is updated.\nNew libs version! The update to the drivers version 17f5d brings new features/fixes:\nsupport for tracing the userfaultd system calls improvements to how libsinsp gathers Kubernetes pod resources limits and pod IP from the container runtime improvement in libsinsp on pod metadata and namespace retrieval for large cluster scenarios, by getting them directly from container labels which is more efficient and use the K8s API server as a fallback fixes to the issues reported by many users on Falco where you can't have a working BPF probe when compiling with Clang \u0026gt;= 10.0.0 fixes to correctly read, when loading the eBPF probe, the license from the BPF binary instead of always reading it from the libscap loader Improvements on building system Finally, it introduces necessary adaptations and improvements to make the Falco building system work with changes recently introduced in libs CMakefiles (in particular by PRs #23 and #30).\nUpdated rules As usual, we keep improving the existing rules and we added new ones, like removing false positives when detecting non-sudo and non-root setuid calls.\nOther false positives has been removed by ignoring additional known Kubernetes service account when watching for service accounts creted in kube-system namespace.\nImprovements have been made also for anti-miner detection, by adding additional domains to be detected.\nFor a complete list please visit the changelog.\nOn the future Now that the libscap, libsinsp, and the two Falco drivers have been contributed to the CNCF, we're moving in the direction of enabling people to benefit from those libraries by using them directly in their OSS projects, as now done by Falco.\nFor this reason we introduced a proposal (thanks to @leodido) about the versioning and the release process of the libs artifacts.\nTry it! As usual, in case you just want to try out the stable Falco 0.29.0, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nNotice that thanks to Jonah, one of our Falco Open Infra maintainers, you can find also the Falcosecurity container images on the public AWS ECR gallery:\nfalco falco-no-driver falco-driver-loader This makes part of an effort to publish Falco container images on other registries that began while cooking up Falco 0.27.0.\nLet'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!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors! Falco reached 100 contributors, but also all the other Falco projects are receiving a vital amount of contributions every day.\nKeep up the good work!\nCiao!\nMax\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.29.0","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-29-0/"},{"category":"blog","content":"Diversity and inclusion are the core values of the CNCF ecosystem. As its incubation project, Falco aligns and functions in the fullest expression of these principles. As we recognize internationalization as a powerful tool to facilitate openness and participation by breaking language barriers, Falco encourages and stands for internationalization (i18n) efforts. With three i18n projects nearing completion and one underway, Falco is leading the way.\nThe goal of i18n is to make Falco easier to use for as many people as possible. To facilitate a smoother initialization into the Falco i18n workflow, we have put together this page. It gives you a broad overview of the i18n process followed by the Falco Community while internationalizing the Falco website.\nInitialize New Language Contributions Before you start, make sure that nobody else is proceeding with your language translation. If there are, please join them. If you are the first one to start the project, review the general Contribution Guidelines.\nIdentify Locale Codes As the first step, identify the locale code associated with your language of choice. You can manually assign the language labels in the pull request (PR) comments.\nFor example, when left as a comment on an issue or PR, the command /kind translation assigns the label kind/translation.\nLocate Files and Directories The files and directories associated with the Falco localization are:\nThe i18n directory: It contains the translated homepage of the Falco website. Each locale will have a file corresponding to the homepage. You should create one corresponding to your language. The content directory: The translated content for blog, documentation, community, and videos resides in the content directory. The configuration file: It is located in the root directory. The TOML file contains the configuration of the static website generator, hugo. It contains settings for the languages, formatting, caches, and so on. Make sure that you create a language sub-section corresponding to your language. OWNERS file: There is an OWNERS file for the Falco website, listing the reviewers and approvers of the project. Similarly, create an OWNERS file for your language project. See the OWNERS file for Malayalam for reference. Choose i18n Tools Choose your favorite language keyboard. Make sure that it works with the markup editor. If not simply use a google doc and its language option, then copy the content to the markup editor.\nContribute to Falco i18n This section helps you start an i18n effort for Falco from scratch.\nFork the Falco Website repository.\nCreate a branch for your translation project. For example: git checkout -b new/language-\u0026lt;lang code\u0026gt;\nReplace language-\u0026lt;lang code\u0026gt; with your language of choice and locale code.\nCreate the \u0026lt;lang code\u0026gt;.yaml file in the i18n directory. In this file, you mainly include the translated content of the home page.\nAdd another [language] sub-section in the config.toml file.\nFor example, for Korean:\ntitle = \u0026#34;Falco\u0026#34; description = \u0026#34;런타임 보안\u0026#34; languageName = \u0026#34;한국어 Korean\u0026#34; weight = 3 contentDir = \u0026#34;content/ko\u0026#34; languagedirection = \u0026#34;ltr\u0026#34; [languages.ko.params] time_format_blog = \u0026quot;2006.01.02\u0026quot; language_alternatives = [\u0026quot;en\u0026quot;] Create a directory, named \u0026lt;lang code\u0026gt;, corresponding to your language in the content directory.\nFor example, content/ml is the directory corresponding to the language, Malayalam.\nNavigate to the language directory that you have just created.\ncd content/\u0026lt;lang code\u0026gt;\nReplace \u0026lt;lang code\u0026gt; with your locale ID.\nCreate a _index.md file in the directory.\nFor example, see the _index.md file corresponding to English.\nTranslate the content to your language.\nCreate a content/\u0026lt;lang code\u0026gt;/docs directory and a corresponding _index.md file in it.\nLikewise, ensure that you create an_index.md file for each directory and sub-directory in the content/\u0026lt;lang code\u0026gt; directory.\nStart with the Getting Started section. Replicate the getting-started directory and its file structure.\nTranslate the content in the Getting Started directory to your language.\nFor example, see the English version of the Getting Started directory.\nEnsure that you sign your commit with git commit -s -m \u0026quot;message”.\nOnce ready create the PR against the master. Make sure you split the effort in smaller units.\nBecome a Maintainer Falco i18n members can review and approve their own PRs. For example, review and approval permissions for English are found in the OWNERS file at the root of the falco-website repository. See GOVERNANCE for more information.\nAs a contributor, make sure that you create an OWNERS file inside the content/\u0026lt;lang code\u0026gt; directory in order to become a maintainer for that localization.\n","summary":"","tags":null,"title":"Internationalize Falco Website","url":"https://v0-43--falcosecurity.netlify.app/blog/i18n-falco-website/"},{"category":"blog","content":" This blog post is part of a series of articles about how to create a Kubernetes response engine with Falco, Falcosidekick and a FaaS.\nSee other posts:\nKubernetes Response Engine, Part 1 : Falcosidekick + Kubeless Kubernetes Response Engine, Part 2 : Falcosidekick + OpenFaas Kubernetes Response Engine, Part 3 : Falcosidekick + Knative Kubernetes Response Engine, Part 4 : Falcosidekick + Tekton Kubernetes Response Engine, Part 6 : Falcosidekick + Cloud Run Kubernetes Response Engine, Part 7: Falcosidekick + Cloud Functions The Open Source ecosystem is very vibrant, there are many ways to create a Kubernetes Response Engine based on our dynamic duo, Falco + Falcosidekick. Today, we will use two components of the CNCF project Argo:\nArgo Events, will receive events from Falcosidekick and push into it event bus. Argo Workflow, will listen the event bus and then trigger the workflow if certain criteria are encountered. Like we did for previous examples with Kubeless, OpenFaas and Knative, we'll address the situation where a shell is spawned in a pod and we want to remediate that by deleting it.\nThis is how we will set this up:\n┌─────────────┐ ┌─────────┐ ┌────────────────┐ │ │ detect │ │ push │ │ │ pwned pod ├───────────► falco ├──────────► falcosidekick ├────┐ │ │ │ │ │ │ │ └──────▲──────┘ └─────────┘ └────────────────┘ │ notify │ │ │ │ delete │ ┌──────────────┐ ┌───────────────┐ ┌──────▼──────┐ │ │ │ │ │ │ │ └───┤ deletion pod ◄──────────┤ argo workflow │ │ argo events │ │ │ create │ │ │ │ └──────────────┘ └────────────▲──┘ └─┬───────────┘ │ │ trigger │ │ push │ │ ┌─┴─────────────▼──┐ │ bus │ └──────────────────┘ Requirements We require a kubernetes cluster running at least 1.17 release, helm and kubectl installed in your locale environment.\nInstallation of Argo Events We simply follow the official documentation.\nkubectl create namespace argo-events kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/manifests/install.yaml kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/manifests/install-validating-webhook.yaml kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/eventbus/native.yaml Installation of Argo Workflow Again, the official documentation will help us.\nkubectl create namespace argo kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo-workflows/stable/manifests/install.yaml kubectl patch -n argo cm workflow-controller-configmap -p \u0026#39;{\u0026#34;data\u0026#34;: {\u0026#34;containerRuntimeExecutor\u0026#34;: \u0026#34;pns\u0026#34;}}\u0026#39; The kubectl patch is there for allowing the workflows to run in minikube, kind, etc. See docs about Workflow Executors to learn more about.\nAfter a while, you should have access to Argo Workflow UI through a dport-forward:\nkubectl port-forward svc/argo-server -n argo 2746:2746 \u0026amp; The link is https://localhost:2746 (you can ignore the certificate error, we're in a lab 😉).\nCreation of the Event Source We'll use an Event Source with Webhook type. It will receive Falco events from Falcosidekick and push them then into the Event Bus.\nThis component is pretty easy to understand. Falcosidekick will have to POST the events to an endpoint /falco of a service opened on port 12000. Easy.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -n argo-events -f - apiVersion: argoproj.io/v1alpha1 kind: EventSource metadata: name: webhook-falco namespace: argo-events spec: service: ports: - port: 12000 targetPort: 12000 webhook: # event-source can run multiple HTTP servers. Simply define a unique port to start a new HTTP server falco-event: # port to run HTTP server on port: \u0026#34;12000\u0026#34; # endpoint to listen to endpoint: /falco # HTTP request method to allow. In this case, only POST requests are accepted method: POST EOF As expected, we now have a new service which will listen events from Falcosidekick on port 12000 and endpoint /falco:\nkubectl get svc -n argo-events NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE webhook-falco-eventsource-svc ClusterIP 10.43.117.26 \u0026lt;none\u0026gt; 12000/TCP 11m Creation of the Sensor\nIn Argo Events architecture, Sensors are responsible for listening to the Event Bus and triggering something should the criteria we set match. In our case, our Sensor:\nlisten only events for pushed by webhook-falco Event Source consider only events where the body (in JSON) contains the value Terminal shell in container for field with key rule, we want to match for only this Falco rule in one word. trigger a workflow based on a template with our event as input First, create the Service Account which allows our Sensor will.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -n argo-events -f - apiVersion: v1 kind: ServiceAccount metadata: namespace: argo-events name: sensor-terminal-shell-container-sa --- # Similarly you can use a ClusterRole and ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: sensor-terminal-shell-container-role namespace: argo-events rules: - apiGroups: - argoproj.io verbs: - \u0026#34;*\u0026#34; resources: - workflows - workflowtemplates - cronworkflows - clusterworkflowtemplates --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: sensor-terminal-shell-container-role-binding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: sensor-terminal-shell-container-role subjects: - kind: ServiceAccount name: sensor-terminal-shell-container-sa namespace: argo-events EOF And now we deploy our Sensor.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -n argo-events -f - apiVersion: argoproj.io/v1alpha1 kind: Sensor metadata: name: terminal-shell-container namespace: argo-events spec: template: serviceAccountName: sensor-terminal-shell-container-sa dependencies: - name: falco-event eventSourceName: webhook-falco eventName: falco-event filters: data: - path: body.rule type: string value: - \u0026#34;Terminal shell in container\u0026#34; triggers: - template: name: delete-pod-trigger argoWorkflow: group: argoproj.io version: v1alpha1 resource: workflows operation: submit parameters: - src: dependencyName: falco-event dest: spec.arguments.parameters.0.value source: resource: apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: delete-pod- namespace: argo spec: workflowTemplateRef: name: delete-pod-template arguments: parameters: - name: falco-event value: {} EOF Creation of the Workflow Template There is one piece missing in our Argo stack, we mentioned a template above, we logically need to create it too, with the service account it needs.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -n argo -f - apiVersion: v1 kind: ServiceAccount metadata: name: delete-pod-sa namespace: argo --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: delete-pod-sa-cluster-role rules: - apiGroups: [\u0026#34;\u0026#34;] resources: [\u0026#34;pods\u0026#34;] verbs: [\u0026#34;get\u0026#34;, \u0026#34;list\u0026#34;, \u0026#34;delete\u0026#34;, \u0026#34;patch\u0026#34;, \u0026#34;watch\u0026#34;] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: delete-pod-sa-cluster-role-binding roleRef: kind: ClusterRole name: delete-pod-sa-cluster-role apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: delete-pod-sa namespace: argo EOF cat \u0026lt;\u0026lt;EOF | kubectl apply -n argo -f - apiVersion: argoproj.io/v1alpha1 kind: WorkflowTemplate metadata: name: delete-pod-template namespace: argo spec: entrypoint: delete-pod serviceAccountName: delete-pod-sa arguments: parameters: - name: falco-event value: \u0026#34;{}\u0026#34; templates: - name: delete-pod inputs: parameters: - name: falco-event container: image: devopps/kubernetes-response-engine-based-on-event-driven-workflow@sha256:22ee203a33fe88f0f99968daebdcea0ca52c8a3d6f7af4c823ed78ac15b7c5db env: - name: BODY value: \u0026#34;{{inputs.parameters.falco-event}}\u0026#34; EOF Argo Workflow runs all workflow steps inside their own pods, we'll use for this tutorial a Golang image developped by @developer-guy (who wrote the Part 2 of this series 😄), the sources are there.\nAt this stage, everything is ready to receive events from Falco and protect our cluster. If you go in Argo Workflow UI you will find the architecture we described at beginning.\nInstallation of Falco and Falcosidekick Last but not least, it's time to install our beloved Falco and Falcosidekick and connect them to our shiny new Response Engine.\nAs with other posts of this series we'll use Helm as conveniant installation method.\nkubectl create ns falco helm repo add falcosecurity https://falcosecurity.github.io/charts\nhelm install falco falcosecurity/falco --namespace falco --set falcosidekick.enabled=true --set falcosidekick.config.webhook.address=http://webhook-falco-eventsource-svc.argo-events.svc.cluster.local:12000/falco Remember the service we \u0026quot;mentioned\u0026quot; earlier? This is it in its FQDN format as an endpoint.\nTest our Response Engine Let's delete pwned pod !\nWe'll simulate a webshell by executing a shell command into a running pod.\nkubectl run alpine -n default --image=alpine --restart=\u0026#39;Never\u0026#39; -- sh -c \u0026#34;sleep 6000\u0026#34; kubectl get pods -n default NAME READY STATUS RESTARTS AGE alpine 1/1 Running 0 8s Run a shell command inside.\nkubectl exec -i --tty alpine -n default -- sh -c \u0026#34;uptime\u0026#34; 22:03:23 up 44 min, load average: 0.07, 0.13, 0.19 If you're quick enough, you may see the termination of the pod.\nkubectl get pods -n default NAME READY STATUS RESTARTS AGE alpine 1/1 Terminating 0 8s And in Argo Workflow UI.\n👍\nGo a little further with Argo We can even go further by deploying all components with Argo CD, another project from Argo team. You can find out all you need in this repo.\nHere a quick demo of the results with the exact same workflow we just created in this tutorial. Conclusion We got another way to create a Response Engine with amazing pieces of software from Open Source world. Of course, it's just the beginning, feel free to share your functions and workflows with the community for starting the creation of a true library of remediation methods.\nIf you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Integration"],"title":"Kubernetes Response Engine, Part 5: Falcosidekick + Argo","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-response-engine-part-5-argo/"},{"category":"blog","content":"Introduction We might not know that Falco is not just for detecting malicious behavior that involves making Linux system calls, in addition to that, Falco v0.13.0 adds Kubernetes Audit Events to the list of supported event sources. That means that, once your cluster is configured with audit log enabled, you can send audit logs as events to Falco, then, you can write Falco rules that can read these events and detect malicious or other notable activity. After that, you can send notifications about the malicious activities or set up a Kubernetes Response Engine to take any action based on them. If you want to take a look at the rules which Falco provides for Kubernetes Audit logs, you can refer to this link. Also, if you want to learn more about that Kubernetes Response Engine is, there is series of articles about how to create a Kubernetes response engine with Falco, Falcosidekick and a FaaS.\nKubernetes Response Engine, Part 1 : Falcosidekick + Kubeless Kubernetes Response Engine, Part 2 : Falcosidekick + OpenFaas Kubernetes Response Engine, Part 3 : Falcosidekick + Knative Kubernetes Response Engine, Part 4: Falcosidekick + Tekton Kubernetes Response Engine, Part 5: Falcosidekick + Argo Without further ado, let's explain what Audit Logs are, and which useful pieces of information that they have for us.\nWe can assume that Kubernetes API Server is like the brain of the cluster. We all communicate with the cluster through Kubernetes API Server, which means that all the requests hit Kubernetes API Server first. So, sometimes we might want to know that what’s happening inside of that brain. At this point, the Kubernetes Audit Log comes into the picture.\nKubernetes Audit Logs are the records that explain what’s happening inside of this brain but if we look at them more technically the official documentation says Kubernetes Audit logs provide a security-relevant, chronological set of records documenting the sequence of actions in a cluster., so by collecting and analyzing them we can answer these following questions:\nWhat happened? When did it happen? Who initiated it? On what did it happen? To get more detail about them, you can refer to this link.\nIn this guide, I'll explain the following topics:\nHow you can enable Audit log feature in Kubernetes. How you can enable the embedded web server available within the Falco project. The purpose of the Falcosidekick project. Prerequisites We need tools with the following minimum versions to achieve this demo:\nmultipass v1.6.2 k3sup v0.11.0 kubectl v1.21.1 helm v3.5.4+g1b5edb6 Tutorial Provision local Kubernetes Cluster There are various ways to provision a local Kubernetes cluster such as, KinD, k3s, k0s, Minikube etc. We are going to use k3s in this walkthrough, we're also going to use some tooling to make the installation process of k3s cluster easier and quicker such as k3sup and multipass.\nLet's get provision a local Kubernetes cluster:\n# Create a ssh key for the instance $ ssh-keygen -t rsa -b 4096 -C \u0026#34;test@test.com\u0026#34; Generating public/private rsa key pair. Enter file in which to save the key (/Users/batuhan.apaydin/.ssh/id_rsa): k3s_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in k3s_rsa. Your public key has been saved in k3s_rsa.pub. The key fingerprint is: SHA256:Ohpm8fRg3E4Gtl6kcVKHPPaeZkx9Zt6KRgrjc4ToGP0 test@test.com The key\u0026#39;s randomart image is: +---[RSA 4096]----+ | .... | | .=. | | =.oo . | | o X o . + | | ..B.S= . = . | | .*oO+ B . . .| | ++=oo* o . . | | o.o..E o o . | | . o . | +----[SHA256]-----+ $ ls -latr total 16 drwxr-xr-x 112 batuhan.apaydin staff 3584 May 22 18:22 .. -rw------- 1 batuhan.apaydin staff 3381 May 22 18:24 k3s_rsa drwxr-xr-x 4 batuhan.apaydin staff 128 May 22 18:24 . -rw-r--r-- 1 batuhan.apaydin staff 739 May 22 18:24 k3s_rsa.pub # Create a file called cloud-init.yaml, this file makes sure the public key is stored on the virtual machine once it’s created $ cat \u0026lt;\u0026lt; EOF | tee cloud-init.yaml ssh_authorized_keys: - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC/qWh+VU1nAm3dTPOiEbCSsW841TAE0IT9bDBWPHJ62a90QVQCdrwl0VVIu6RreH2CpCqjdyWzJ/ZZ9KiUU2lkCGlLfo1ExEu3QqlTrjSgRY4BQSaXTJsJmSWojgtiXijObiadUfQsagdG2ZZD78c6T0lKrg1bCyjedJC9xx4MKVGhRvCw4IcJ+RAyZzTSF6XbqG0FDgCYLtKRbPZpy4KWtENXvWAmdKZbeiyO9RjUkPmWjK0Kk1YAekYTjFxia+KJE3Vx6gIhRH+no7PeizkSyKG6cMXE4DyW2OkIQzfb82K2MWS2jORiIFpU1/FtFytu6Enpj1OE8j1vJLjrzcKHH7HEHvSzWtpIZ6H3dYFxavaBcmgsZJX7fXfm8nguI87NQ0F1JFzSIibz2F0ICybN9rQShPc0cHizZHV/lWRlBV1qUvaY1c7O6CTnRdOVXqSj+a9c6C5SEEe/+Ml2Sqnmyrg6c0k1IxMXR2yDDSgWBzzTPdR4E8OSzD7W2FpzMmYR+9SREPYyY9cOO/Lw8zKdhLnHG1YKmzuX2h4sJN2xtmjMSKvSKJCuSInzZjn6HVZF4FRIouI7I0LLv4rASOLpTmAFF2PqNxhB8bGCwYHnJXhzQCONyG8eTOCraaheNJOnhSjfSVSZyCPDYNrp7KdBkU6tqvDzHFJ6MNuJYTI94Q== test@test.com EOF # Create an instance named k3s-leader with the given details $ multipass launch --name k3s-leader --cpus 2 --mem 2048M --disk 10G --cloud-init cloud-init.yaml Launched: k3s-leader # Get the IP address of the server $ export K3S_IP_SERVER=\u0026#34;$(multipass info k3s-leader | grep \u0026#34;IPv4\u0026#34; | awk -F\u0026#39; \u0026#39; \u0026#39;{print $2}\u0026#39;)\u0026#34; $ echo $K3S_IP_SERVER https://192.168.64.26:6443 # Set up k3s on server by using k3sup $ k3sup install --ip $K3S_IP_SERVER --user ubuntu --k3s-extra-args \u0026#34;--cluster-init\u0026#34; --ssh-key k3s_rsa Running: k3sup install 2021/05/22 18:32:51 192.168.64.26 Public IP: 192.168.64.26 [INFO] Finding release for channel v1.19 [INFO] Using v1.19.11+k3s1 as release [INFO] Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.19.11+k3s1/sha256sum-amd64.txt [INFO] Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.19.11+k3s1/k3s [INFO] Verifying binary download [INFO] Installing k3s to /usr/local/bin/k3s [INFO] Creating /usr/local/bin/kubectl symlink to k3s [INFO] Creating /usr/local/bin/crictl symlink to k3s [INFO] Creating /usr/local/bin/ctr symlink to k3s [INFO] Creating killall script /usr/local/bin/k3s-killall.sh [INFO] Creating uninstall script /usr/local/bin/k3s-uninstall.sh [INFO] env: Creating environment file /etc/systemd/system/k3s.service.env [INFO] systemd: Creating service file /etc/systemd/system/k3s.service [INFO] systemd: Enabling k3s unit Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service. [INFO] systemd: Starting k3s Result: [INFO] Finding release for channel v1.19 [INFO] Using v1.19.11+k3s1 as release [INFO] Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.19.11+k3s1/sha256sum-amd64.txt [INFO] Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.19.11+k3s1/k3s [INFO] Verifying binary download [INFO] Installing k3s to /usr/local/bin/k3s [INFO] Creating /usr/local/bin/kubectl symlink to k3s [INFO] Creating /usr/local/bin/crictl symlink to k3s [INFO] Creating /usr/local/bin/ctr symlink to k3s [INFO] Creating killall script /usr/local/bin/k3s-killall.sh [INFO] Creating uninstall script /usr/local/bin/k3s-uninstall.sh [INFO] env: Creating environment file /etc/systemd/system/k3s.service.env [INFO] systemd: Creating service file /etc/systemd/system/k3s.service [INFO] systemd: Enabling k3s unit [INFO] systemd: Starting k3s Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service. Saving file to: /Users/batuhan.apaydin/workspace/projects/personal/poc/audit-log-falco-k3s/kubeconfig # Test your cluster with: export KUBECONFIG=/Users/batuhan.apaydin/workspace/projects/personal/poc/audit-log-falco-k3s/kubeconfig kubectl config set-context default kubectl get node -o wide # Set KUBECONFIG environment variable to work with kubectl $ export KUBECONFIG=/Users/batuhan.apaydin/workspace/projects/personal/poc/audit-log-falco-k3s/kubeconfig Verify if everything is working before move on to the next step.\n$ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME k3s-leader Ready etcd,master 93s v1.19.11+k3s1 192.168.64.26 \u0026lt;none\u0026gt; Ubuntu 20.04.2 LTS 5.4.0-73-generic containerd://1.4.4-k3s1 Install Falco and Falcosidekick with Auditing Feature Enabled We'll use Helm to install the Falco, so, there is an option that we can enable or disable the audit log feature called auditLog.enabled, once we set the value of the option as true, the embedded webserver will be started within the Falco to consume audit events from the port 8765 and behind k8s-audit endpoint.\nFirstly, we'll create the namespace that will host both Falco and Falcosidekick:\n$ kubectl create namespace falco namespace/falco created We add the helm repo:\n$ helm repo add falcosecurity https://falcosecurity.github.io/charts \u0026#34;falcosecurity\u0026#34; has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the \u0026#34;falcosecurity\u0026#34; chart repository In a real project, you should get the whole chart with helm pull falcosecurity/falco --untar and then configure the values.yaml. For this tutorial, will try to keep thing as easy as possible and set configs directly by passing arguments to helm install command line:\n$ helm upgrade --install falco falcosecurity/falco --namespace falco \\ --set falcosidekick.enabled=true \\ --set falcosidekick.webui.enabled=true \\ --set auditLog.enabled=true You should get this output:\nRelease \u0026#34;falco\u0026#34; does not exist. Installing it now. NAME: falco LAST DEPLOYED: Tue Apr 13 10:49:49 2021 NAMESPACE: falco STATUS: deployed REVISION: 1 NOTES: Falco agents are spinning up on each node in your cluster. After a few seconds, they are going to start monitoring your containers looking for security issues. No further action should be required. And you can see your new Falco and Falcosidekick pods:\n$ kubectl get pods --namespace falco NAME READY STATUS RESTARTS AGE falco-2tqn8 1/1 Running 0 10m falco-falcosidekick-fb6f8b856-fz9nt 1/1 Running 0 10m falco-falcosidekick-fb6f8b856-wjvzx 1/1 Running 0 10m falco-falcosidekick-ui-7c5fc8dd54-gdkbz 1/1 Running 0 10m Check your services within the namespace falco, and you should see that Falco service has 8765 port, let's verify that.\n$ kubectl get services --namespace falco NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE falco ClusterIP 10.43.209.197 \u0026lt;none\u0026gt; 8765/TCP 12m # here is important. falco-falcosidekick ClusterIP 10.43.77.241 \u0026lt;none\u0026gt; 2801/TCP 12m falco-falcosidekick-ui ClusterIP 10.43.197.181 \u0026lt;none\u0026gt; 2802/TCP 12m The argument falcosidekick.enabled=true sets the following settings in Falco for you:\n--set falco.jsonOutput=true \\ --set falco.httpOutput.enabled=true \\ --set falco.httpOutput.url=http://falco-falcosidekick:2801 The arguments --set falco.jsonOutput=true --set falco.httpOutput.enabled=true --set falco.httpOutput.url=http://falco-falcosidekick:2801 are there to configure the format of events and the URL where Falco will send them. As Falco and Falcosidekick will be in the same namespace, it can directly use the name of the service(falco-falcosidekick) above Falcosidekick pods.\nWe check the logs:\n$ kubectl logs deployment/falco-falcosidekick --namespace falco Found 2 pods, using pod/falco-falcosidekick-fb6f8b856-wjvzx 2021/05/22 15:46:58 [INFO] : Enabled Outputs : [WebUI] 2021/05/22 15:46:58 [INFO] : Falco Sidekick is up and listening on :2801 WebUI is displayed as enabled output, everything is good 👍.\nEnabling Kubernetes Audit Logs To enable Kubernetes audit logs, you need to change the arguments to the kube-apiserver process to add --audit-policy-file and --audit-webhook-config-file arguments and provide files that implement an audit policy/webhook configuration.\nLet's do that.\n$ multipass shell k3s-leader ubuntu@k3s-leader:~$ sudo mkdir -p /var/lib/rancher/audit ubuntu@k3s-leader:~$ wget https://raw.githubusercontent.com/falcosecurity/evolution/master/examples/k8s_audit_config/audit-policy.yaml -P /var/lib/rancher/audit ubuntu@k3s-leader:~$ FALCO_CLUSTER_IP=$(sudo kubectl get service --namespace falco falco -o=jsonpath={.spec.clusterIP}) ubuntu@k3s-leader:~$ cat \u0026lt;\u0026lt; EOF | sudo tee /var/lib/rancher/audit/webhook-config.yaml apiVersion: v1 kind: Config clusters: - name: falco cluster: server: http://$FALCO_CLUSTER_IP:8765/k8s-audit contexts: - context: cluster: falco user: \u0026#34;\u0026#34; name: default-context current-context: default-context preferences: {} users: [] EOF Once you created the necessary files, we should update k3s.service Unit file.\nubuntu@k3s-leader:~$ vim /etc/systemd/system/k3s.service # add these lines to after the k3s server command. # --kube-apiserver-arg=audit-log-path=/var/lib/rancher/audit/audit.log # --kube-apiserver-arg=audit-policy-file=/var/lib/rancher/audit/audit-policy.yaml # --kube-apiserver-arg=audit-webhook-config-file=/var/lib/rancher/audit/webhook-config.yaml The final k3s.service Unit file should looks like the following:\n[Unit] Description=Lightweight Kubernetes Documentation=https://k3s.io Wants=network-online.target After=network-online.target [Install] WantedBy=multi-user.target [Service] Type=notify EnvironmentFile=-/etc/default/%N EnvironmentFile=-/etc/sysconfig/%N EnvironmentFile=-/etc/systemd/system/k3s.service.env KillMode=process Delegate=yes # Having non-zero Limit*s causes performance problems due to accounting overhead # in the kernel. We recommend using cgroups to do container-local accounting. LimitNOFILE=1048576 LimitNPROC=infinity LimitCORE=infinity TasksMax=infinity TimeoutStartSec=0 Restart=always RestartSec=5s ExecStartPre=-/sbin/modprobe br_netfilter ExecStartPre=-/sbin/modprobe overlay ExecStart=/usr/local/bin/k3s \\ server \\ \u0026#39;--tls-san\u0026#39; \\ \u0026#39;192.168.64.26\u0026#39; \\ \u0026#39;--cluster-init\u0026#39; \\ \u0026#39;--kube-apiserver-arg=audit-log-path=/var/lib/rancher/audit/audit.log\u0026#39; \\ \u0026#39;--kube-apiserver-arg=audit-policy-file=/var/lib/rancher/audit/audit-policy.yaml\u0026#39; \\ \u0026#39;--kube-apiserver-arg=audit-webhook-config-file=/var/lib/rancher/audit/webhook-config.yaml\u0026#39; Save this file and restart k3s service.\nubuntu@k3s-leader:~$ sudo systemctl daemon-reload \u0026amp;\u0026amp; sudo systemctl restart k3s Verify if everything is working before move on to the next step.\nubuntu@k3s-leader:~$ sudo systemctl status k3s.service ● k3s.service - Lightweight Kubernetes Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor pres\u0026gt; Active: active (running) since Sat 2021-05-22 19:46:06 +03; 8min ago Docs: https://k3s.io Process: 15250 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, \u0026gt; Process: 15251 ExecStartPre=/sbin/modprobe overlay (code=exited, statu\u0026gt; Main PID: 15252 (k3s-server) Tasks: 144 Memory: 1.2G CGroup: /system.slice/k3s.service ... Now we are ready to test everything.\nTest There is a rule called Create/Modify Configmap With Private Credentials in Falco for detecting ConfigMaps that contains private credentials from Kubernetes Audit Logs, you can see the details of the rule from this link. In order to test this, we should create a ConfigMap that contains private credentials, but before doing that, let's access the Falcosidekick Web UI to see what will happen once we create the malicious ConfigMap.\n$ kubectl --namespace=falco port-forward svc/falco-falcosidekick-ui 2802 Forwarding from 127.0.0.1:2802 -\u0026gt; 2802 Forwarding from [::1]:2802 -\u0026gt; 2802 Now, let's create the ConfigMap.\n$ kubectl create configmap aws-creds \\ --from-literal aws_access_key_id=AKES20LNOA configmap/aws-creds created As soon as you created the ConfigMap, Falco will detect that from the audit logs, and send an alert for that to the Falcosidekick. Finally, Falcosidekick forwards the alert to the Web UI. So, you should see a screen similar to the following:\nConclusion With this really simple example, we only scratched the surface of possibilities, so don't hesitate to share with us on Slack (https://kubernetes.slack.com #falco) your comments, ideas and successes. You're also always welcome to contribute.\n","summary":"","tags":null,"title":"Detect Malicious Behaviour on Kubernetes API Server through Audit Logs","url":"https://v0-43--falcosecurity.netlify.app/blog/detect-malicious-behaviour-on-kubernetes-api-server-through-audit-logs/"},{"category":"blog","content":" This blog post is part of a series of articles about how to create a Kubernetes response engine with Falco, Falcosidekick and a FaaS.\nSee other posts:\nKubernetes Response Engine, Part 1 : Falcosidekick + Kubeless Kubernetes Response Engine, Part 2 : Falcosidekick + OpenFaas Kubernetes Response Engine, Part 3 : Falcosidekick + Knative Kubernetes Response Engine, Part 5 : Falcosidekick + Argo Kubernetes Response Engine, Part 6 : Falcosidekick + Cloud Run Kubernetes Response Engine, Part 7: Falcosidekick + Cloud Functions Falcosidekick + Tekton Earler in this series we have seen how to use Kubeless, OpenFaas and Knative to trigger a pod after getting input from falcosidekick to delete a compromised pod.\nIn this part I will showcase how we can use Tekton and not have to add any extra complexity to your cluster by adding a serverless runtime.\nI won't go through how Tekton works in depth but, you can find a good overview in the official docs. But here is the crash course:\nTekton is built to be reusable. The smallest part of tekton is a step, a step can be something like this: Run unit tests Run linting In a task you can have multiple steps. A pipeline consist of one or multiple tasks. To trigger a pipeline to actually run you need a pipelinerun or a trigger-template. Tekton also supports eventlisteners that is used to listen for webhooks. Normally these webhooks listen for incoming changes to a git repo, for example a PR. But we will use it to listen for Falco events.\nYou can find all the yaml and code in my repo.\nPrerequisites As always within Kubernetes we need a few tools, I have used the following versions of Helm, Minikube and kubectl in my setup.\nMinikube v1.19.0 Helm v3.4.2 kubectl v1.20.5 Provision local Kubernetes Cluster I'm sure you can use a kind cluster as well to follow along, but falco complained a bit when I tried and I was too lazy to check out what extra flags I need so I went with minikube.\nminikube start --cpus 3 --memory 8192 --vm-driver virtualbox Install Tekton Install Tekton pipelines and triggers. When doing this in production I recommend the Tekton operator but for now let us use some pure yaml.\nkubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml kubectl apply --filename https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml Within a few seconds you should be able to see a few pods in the tekton-pipelines namespace.\nkubectl get pods -n tekton-pipelines NAME READY STATUS RESTARTS AGE tekton-pipelines-controller-6b94f5f96-cmf8m 1/1 Running 0 1h tekton-pipelines-webhook-5bfbbd6475-fmjp4 1/1 Running 0 1h tekton-triggers-controller-7cbd49fbb8-p4lrz 1/1 Running 0 1h tekton-triggers-webhook-748fb7778c-w6zxv 1/1 Running 0 1h If you want a deeper understanding how Tekton triggers work check out the getting-started guide.\nInstall Falco + Falcosidekick Create the falco namespace and add the helm repo:\nkubectl create namespace falco helm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update For simplicity and long term usability let us create a custom values file and start falco.\ncat \u0026lt;\u0026lt;\u0026#39;EOF\u0026#39; \u0026gt;\u0026gt; values.yaml falcosidekick: config: webhook: address: http://el-falco-listener.falcoresponse.svc.cluster.local:8080 enabled: true customRules: # Applications which are expected to communicate with the Kubernetes API rules_user_known_k8s_api_callers.yaml: |- - macro: user_known_contact_k8s_api_server_activities condition: \u0026gt; (container.image.repository = \u0026#34;gcr.io/tekton-releases/github.com/tektoncd/triggers/cmd/eventlistenersink\u0026#34;) or (container.image.repository = \u0026#34;quay.io/nissessenap/poddeleter\u0026#34;) EOF # Install falco helm upgrade --install falco falcosecurity/falco --namespace falco -f values.yaml Note the customRules and the webhook address.\nWe haven't setup this webhook address nor is there currently any reason for us to have customRules for eventlistenersink or poddeleter, but it will come. Both the Tekton event listener and my poddeleter does a few kubernetes API calls and we don't want falco generate alarms for our own infrastructure.\nYou should be able to see falco and falcosidekick pods in the falco namespace:\nkubectl get pods --namespace falco NAME READY STATUS RESTARTS AGE falco-44p4v 1/1 Running 0 64m falco-falcosidekick-779b87f446-8zf9m 1/1 Running 0 2h falco-falcosidekick-779b87f446-fdk55 1/1 Running 0 2h Protect me Falco My current setup is rather harsh and will delete any pods that breaks any falco rule. In the future I plan to make both the go code and the tekton setup better and more flexible, hopefully this is something that we can do in the community.\nDuring this demo I will use the Terminal Shell in container since it's very easy to reproduce.\nSo how does all this work?\nWe start a random pod and perform a simple exec. Falco will notice that a pod have broken the rule Sends an event to Falcosidekick Sends a webhook to tekton event-listener Tekton triggers a new pipeline A task is started with a small go program that deletes the pod So let us look at some yaml.\nThe go code I have adapted the code that Batuhan Apaydın wrote in Falcosidekick + OpenFaas = a Kubernetes Response Engine, Part 2 to listen for json in an environment variable instead of a http request.\nBelow you can see the code, in short it does the following:\nCheck for environment variable BODY. Unmarshal the data according to the Alert struct. Setups a kubernetes client, by calling setupKubeClient function. Calls the deletePod with a kubernetes client, the falcoEvent we gotten and a hash map of critical Namespaces. Check in the event that we got from falcosidekick and see if the pod that triggered the event is in our critical namespaces hash map. If it is return to the main and shutdown the application. Else deletes the pod in the namespace specified in the falcosidekick event. package main import ( \u0026#34;context\u0026#34; \u0026#34;encoding/json\u0026#34; \u0026#34;log\u0026#34; \u0026#34;os\u0026#34; \u0026#34;time\u0026#34; metaV1 \u0026#34;k8s.io/apimachinery/pkg/apis/meta/v1\u0026#34; \u0026#34;k8s.io/client-go/kubernetes\u0026#34; \u0026#34;k8s.io/client-go/rest\u0026#34; ) // Alert falco data structure type Alert struct { Output string `json:\u0026#34;output\u0026#34;` Priority string `json:\u0026#34;priority\u0026#34;` Rule string `json:\u0026#34;rule\u0026#34;` Time time.Time `json:\u0026#34;time\u0026#34;` OutputFields struct { ContainerID string `json:\u0026#34;container.id\u0026#34;` ContainerImageRepository interface{} `json:\u0026#34;container.image.repository\u0026#34;` ContainerImageTag interface{} `json:\u0026#34;container.image.tag\u0026#34;` EvtTime int64 `json:\u0026#34;evt.time\u0026#34;` FdName string `json:\u0026#34;fd.name\u0026#34;` K8SNsName string `json:\u0026#34;k8s.ns.name\u0026#34;` K8SPodName string `json:\u0026#34;k8s.pod.name\u0026#34;` ProcCmdline string `json:\u0026#34;proc.cmdline\u0026#34;` } `json:\u0026#34;output_fields\u0026#34;` } func main() { criticalNamespaces := map[string]bool{ \u0026#34;kube-system\u0026#34;: true, \u0026#34;kube-public\u0026#34;: true, \u0026#34;kube-node-lease\u0026#34;: true, \u0026#34;falco\u0026#34;: true, } var falcoEvent Alert bodyReq := os.Getenv(\u0026#34;BODY\u0026#34;) if bodyReq == \u0026#34;\u0026#34; { log.Fatalf(\u0026#34;Need to get environment variable BODY\u0026#34;) } bodyReqByte := []byte(bodyReq) err := json.Unmarshal(bodyReqByte, \u0026amp;falcoEvent) if err != nil { log.Fatalf(\u0026#34;The data doesent match the struct %v\u0026#34;, err) } kubeClient, err := setupKubeClient() if err != nil { log.Fatalf(\u0026#34;Unable to create in-cluster config: %v\u0026#34;, err) } err = deletePod(kubeClient, falcoEvent, criticalNamespaces) if err != nil { log.Fatalf(\u0026#34;Unable to delete pod due to err %v\u0026#34;, err) } } // setupKubeClient func setupKubeClient() (*kubernetes.Clientset, error) { config, err := rest.InClusterConfig() if err != nil { return nil, err } // creates the clientset kubeClient, err := kubernetes.NewForConfig(config) if err != nil { return nil, err } return kubeClient, nil } // deletePod, if not part of the criticalNamespaces the pod will be deleted func deletePod(kubeClient *kubernetes.Clientset, falcoEvent Alert, criticalNamespaces map[string]bool) error { podName := falcoEvent.OutputFields.K8SPodName namespace := falcoEvent.OutputFields.K8SNsName log.Printf(\u0026#34;PodName: %v \u0026amp; Namespace: %v\u0026#34;, podName, namespace) log.Printf(\u0026#34;Rule: %v\u0026#34;, falcoEvent.Rule) if criticalNamespaces[namespace] { log.Printf(\u0026#34;The pod %v won\u0026#39;t be deleted due to it\u0026#39;s part of the critical ns list: %v \u0026#34;, podName, namespace) return nil } log.Printf(\u0026#34;Deleting pod %s from namespace %s\u0026#34;, podName, namespace) err := kubeClient.CoreV1().Pods(namespace).Delete(context.Background(), podName, metaV1.DeleteOptions{}) if err != nil { return err } return nil } If you rather see it in github.\nNow that you know what I will make run in your cluster let us take a look at the Tekton yaml.\nTekton pipeline Create the falcoresponse namespace to do our tests in.\nkubectl create ns falcoresponse Task So let us start with the smallest part, the task.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: pod-delete namespace: falcoresponse spec: params: - name: falco-event description: The entire msg from falco steps: - name: pod-delete image: quay.io/nissessenap/poddeleter@sha256:ae94ec2c9f005573e31e4944d1055a0dd92ee7594e7e7e36a4540a1811977270 env: - name: BODY value: \\$(params.falco-event) EOF The task needs a input variable falco-event. The step called pod-delete uses the poddeleter image. Step pod-delete sets the environment BODY from the input parameter called falco-event. Pipeline Here you can see the reusability of tekton. This pipeline can easily add more tasks and other pipelines can use the exact same task as this one.\nJust like the task this pipeline expects a parameter called falco-event which it sends in to the pod-delete task.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: pod-delete-pipeline namespace: falcoresponse spec: params: - name: falco-event description: The entire msg from falco tasks: - name: run-pod-delete taskRef: name: pod-delete params: - name: falco-event value: \\$(params.falco-event) EOF RBAC We will be using two separate serviceAccounts, one for the event-listener and one for the poddeleter it self.\nSo let us create these serviceAccounts and give them some access.\nBelow you can find the event listener RBAC config.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: v1 kind: ServiceAccount metadata: name: tekton-triggers-example-sa namespace: falcoresponse --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: tekton-triggers-example-minimal namespace: falcoresponse rules: # EventListeners need to be able to fetch all namespaced resources - apiGroups: [\u0026#34;triggers.tekton.dev\u0026#34;] resources: [\u0026#34;eventlisteners\u0026#34;, \u0026#34;triggerbindings\u0026#34;, \u0026#34;triggertemplates\u0026#34;, \u0026#34;triggers\u0026#34;] verbs: [\u0026#34;get\u0026#34;, \u0026#34;list\u0026#34;, \u0026#34;watch\u0026#34;] - apiGroups: [\u0026#34;\u0026#34;] # configmaps is needed for updating logging config resources: [\u0026#34;configmaps\u0026#34;] verbs: [\u0026#34;get\u0026#34;, \u0026#34;list\u0026#34;, \u0026#34;watch\u0026#34;] # Permissions to create resources in associated TriggerTemplates - apiGroups: [\u0026#34;tekton.dev\u0026#34;] resources: [\u0026#34;pipelineruns\u0026#34;, \u0026#34;pipelineresources\u0026#34;, \u0026#34;taskruns\u0026#34;] verbs: [\u0026#34;create\u0026#34;] - apiGroups: [\u0026#34;\u0026#34;] resources: [\u0026#34;serviceaccounts\u0026#34;] verbs: [\u0026#34;impersonate\u0026#34;] - apiGroups: [\u0026#34;policy\u0026#34;] resources: [\u0026#34;podsecuritypolicies\u0026#34;] resourceNames: [\u0026#34;tekton-triggers\u0026#34;] verbs: [\u0026#34;use\u0026#34;] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: tekton-triggers-example-binding namespace: falcoresponse subjects: - kind: ServiceAccount name: tekton-triggers-example-sa roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: tekton-triggers-example-minimal --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: tekton-triggers-example-clusterrole rules: # EventListeners need to be able to fetch any clustertriggerbindings - apiGroups: [\u0026#34;triggers.tekton.dev\u0026#34;] resources: [\u0026#34;clustertriggerbindings\u0026#34;, \u0026#34;clusterinterceptors\u0026#34;] verbs: [\u0026#34;get\u0026#34;, \u0026#34;list\u0026#34;, \u0026#34;watch\u0026#34;] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: tekton-triggers-example-clusterbinding subjects: - kind: ServiceAccount name: tekton-triggers-example-sa namespace: falcoresponse roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: tekton-triggers-example-clusterrole EOF And here is the poddeleter serviceAccount:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: v1 kind: ServiceAccount metadata: name: falco-pod-delete namespace: falcoresponse --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: falco-pod-delete-cluster-role rules: - apiGroups: [\u0026#34;\u0026#34;] resources: [\u0026#34;pods\u0026#34;] verbs: [\u0026#34;get\u0026#34;, \u0026#34;list\u0026#34;, \u0026#34;delete\u0026#34;] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: falco-pod-delete-cluster-role-binding roleRef: kind: ClusterRole name: falco-pod-delete-cluster-role apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: falco-pod-delete namespace: falcoresponse EOF Event listener Finally time to configure the tekton webhook receiver. Just like rest of Tekton the event listener builds on multiple parts.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: triggers.tekton.dev/v1alpha1 kind: EventListener metadata: name: falco-listener namespace: falcoresponse spec: serviceAccountName: tekton-triggers-example-sa triggers: - name: cel-trig bindings: - ref: falco-pod-delete-binding template: ref: falco-pod-delete-trigger-template EOF It is possible to expose a event listener using a ingress, this is a rather normal use case if you want github to trigger a pipeline for example.\nI cannot stress this enough DO NOT MAKE THE EVENT LISTENER PUBLIC TO THE INTERNET. We haven't added any protection and this task have the power to kill pods in your cluster. Don't give a potential hacker this power!\nThe event listener is rather complex and can do allot. For example one way to improve this tekton pipeline could be to check for a specific Priority from Falco. This could be done with a cel interceptor and filter on body.Priority.\nBut for now let us just trigger on everything.\nThe triggerBinding let us you define what data should be gathered from the incoming webhook. In this case I take the entire request body.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: triggers.tekton.dev/v1alpha1 kind: TriggerBinding metadata: name: falco-pod-delete-binding namespace: falcoresponse spec: params: - name: falco-event value: \\$(body) EOF We use the TriggerTemplate to call on the pipeline that we defined earlier using the parameter that the TriggerBinding gives us.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: triggers.tekton.dev/v1alpha1 kind: TriggerTemplate metadata: name: falco-pod-delete-trigger-template namespace: falcoresponse annotations: triggers.tekton.dev/old-escape-quotes: \u0026#34;true\u0026#34; spec: params: - name: falco-event description: The entire msg from falco resourcetemplates: - apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: generateName: falco-pod-delete-pipeline-run- spec: serviceAccountName: falco-pod-delete pipelineRef: name: pod-delete-pipeline params: - name: falco-event value: \\$(tt.params.falco-event) EOF Notice the annotations, without it the pipeline will never get triggered.\nWe define the serviceAccount to use in our pipeline/task, point to the pipeline that we should use. And what parameter to send down to the pipeline, notice the tt in front of parma. This is special syntax for TriggerBindings.\nThe triggerTemplate was the final piece needed and you should see a pod spinning up in the falcoresponse namespace.\nkubectl get pods -n falcoresponse NAME READY STATUS RESTARTS AGE el-falco-listener-557786f598-zdmw2 1/1 Running 0 2h Trigger job Finally it's time to test our setup.\nI would recommend that you start a second terminal for this part.\nTerminal 1 follow the falco logs:\nkubectl logs -f $(kubectl get pods -l app=falco -o jsonpath=\u0026#34;{.items[0].metadata.name}\u0026#34; -n falco) -n falco Terminal 2 let us trigger the Terminal Shell in container falco rule\n# Start a alpine pod kubectl run alpine --namespace falcoresponse --image=alpine --restart=\u0026#39;Never\u0026#39; -- sh -c \u0026#34;sleep 600\u0026#34; # Trigger the rule breaking behavior kubectl exec -i --tty alpine --namespace falcoresponse -- sh -c \u0026#34;uptime\u0026#34; # Watch for pods in falcoresponse namespace kubectl get pods -n falcoresponse -w In Terminal 1 you should see something like this:\n* Setting up /usr/src links from host * Running falco-driver-loader for: falco version=0.28.0, driver version=5c0b863ddade7a45568c0ac97d037422c9efb750 * Running falco-driver-loader with: driver=module, compile=yes, download=yes * Unloading falco module, if present * Trying to load a system falco module, if present * Success: falco module found and loaded with modprobe Sun May 2 18:00:10 2021: Falco version 0.28.0 (driver version 5c0b863ddade7a45568c0ac97d037422c9efb750) Sun May 2 18:00:10 2021: Falco initialized with configuration file /etc/falco/falco.yaml Sun May 2 18:00:10 2021: Loading rules from file /etc/falco/falco_rules.yaml: Sun May 2 18:00:10 2021: Loading rules from file /etc/falco/falco_rules.local.yaml: Sun May 2 18:00:10 2021: Loading rules from file /etc/falco/rules.d/rules_user_known_k8s_api_callers.yaml: Sun May 2 18:00:10 2021: Starting internal webserver, listening on port 8765 {\u0026#34;output\u0026#34;:\u0026#34;20:24:10.361728219: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=falcoresponse k8s.pod=alpine container=6ac7d190134e shell=sh parent=runc cmdline=sh -c uptime terminal=34816 container_id=6ac7d190134e image=alpine) k8s.ns=falcoresponse k8s.pod=alpine container=6ac7d190134e k8s.ns=falcoresponse k8s.pod=alpine container=6ac7d190134e\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Notice\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Terminal shell in container\u0026#34;,\u0026#34;time\u0026#34;:\u0026#34;2021-05-02T20:24:10.361728219Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;container.id\u0026#34;:\u0026#34;6ac7d190134e\u0026#34;,\u0026#34;container.image.repository\u0026#34;:\u0026#34;alpine\u0026#34;,\u0026#34;evt.time\u0026#34;:1619987050361728219,\u0026#34;k8s.ns.name\u0026#34;:\u0026#34;falcoresponse\u0026#34;,\u0026#34;k8s.pod.name\u0026#34;:\u0026#34;alpine\u0026#34;,\u0026#34;proc.cmdline\u0026#34;:\u0026#34;sh -c uptime\u0026#34;,\u0026#34;proc.name\u0026#34;:\u0026#34;sh\u0026#34;,\u0026#34;proc.pname\u0026#34;:\u0026#34;runc\u0026#34;,\u0026#34;proc.tty\u0026#34;:34816,\u0026#34;user.loginuid\u0026#34;:-1,\u0026#34;user.name\u0026#34;:\u0026#34;root\u0026#34;}} In Terminal 2 you should see a pod starting and hopefully Complete without any errors and the alpine pod getting killed.\nNAME READY STATUS RESTARTS AGE alpine 0/1 Terminating 0 1m7s el-falco-listener-557786f598-znzk9 1/1 Running 0 10m falco-pod-delete-pipeline-run-w2vf8-run-pod-delete-jlxl7--mk44k 0/1 Completed 0 59s Hurray our \u0026quot;hacked\u0026quot; pod have been killed\nIf you look in the logs of the task\nkubectl logs -f $(kubectl get pods -l tekton.dev/task=pod-delete -o jsonpath=\u0026#34;{.items[0].metadata.name}\u0026#34; -n falcoresponse) -n falcoresponse 2021/05/02 18:11:00 PodName: alpine \u0026amp; Namespace: falcoresponse 2021/05/02 18:11:00 Rule: Terminal shell in container 2021/05/02 18:11:00 Deleting pod alpine from namespace falcoresponse Conclusion This was a rather simple example on how we can use the power of tekton together with Falco to protect us from bad actors that is trying to take over pods in our cluster.\nAs noted during this post there are a lot of potential improvements before this is production ready:\nThe criticalNamespaces in our go code is currently hard-coded and needs to be input variable of some kind. We need to be able to delete pods depending on priority level, rule or something similar. To be able to debug pods we might need to shell in to them, we need a way to ignore pods temporary without the pod getting restarted. Probably a annotation to look for in the pod before deleting it. And probably many other needs that you can come up with. If you have any ideas/issues come and share them in the falco slack https://kubernetes.slack.com #falco.\nTekton If you would like to find out more about Tekton:\nGet started in tekton.dev. Check out the Tekton Project in GitHub. Meet the maintainers on the TektonCD Slack. Follow @tektoncd on Twitter. Falco If you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Integration"],"title":"Kubernetes Response Engine, Part 4: Falcosidekick + Tekton","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-response-engine-part-4-tekton/"},{"category":"blog","content":" This blog post is part of a series of articles about how to create a Kubernetes response engine with Falco, Falcosidekick and a FaaS.\nSee other posts:\nKubernetes Response Engine, Part 1 : Falcosidekick + Kubeless Kubernetes Response Engine, Part 2 : Falcosidekick + OpenFaas Kubernetes Response Engine, Part 4 : Falcosidekick + Tekton Kubernetes Response Engine, Part 5 : Falcosidekick + Argo Kubernetes Response Engine, Part 6 : Falcosidekick + Cloud Run Kubernetes Response Engine, Part 7: Falcosidekick + Cloud Functions As the Cloud Native ecosystem grows and the idea that an integrator can browse the offerings and slap them together like an a la carte menu resonates. We call this Thinking Cloud Native.\nFalco already produced events, but in the form of a webhook with bespoke payloads, which is fine, unless you would like to integrate into an ecosystem for event routing. To enable this for Falco we had to think about how these events are moved from producer to consumer via something else. Enter: CloudEvents.\nWhat is CloudEvents? It is a specification for translating an event and the metadata onto a specific protocol and back. What? It lets you think about the event in a generic way without it being tied to particular choices the integration is making today, and with minor effort CloudEvents lets that integration change the protocol choice without changing the meaning of the event.\nThis lossless property of CloudEvents means the integrator is free to choose middleware that also speaks CloudEvents and has its own choices of persistence and protocol, but the consumer of the event need not be aware of these translations that have happened between the producer and consumer.\nThere are several choices that support CloudEvents today: Serverless.com Event Gateway, Argo, Google Cloud Pub/Sub, Azure Event Grid, and Knative Eventing. A more full list is at the cloudevents/spec repo.\nFor this blog post, we are going to focus in on Falco+Knative and see what we can do with that a la carte selection.\nFalco+Knative What is Knative? It is two things: Knative Serving and Knative Eventing. Serving provides a container based scale to zero, scale real big functionality; as well as rainbow deploys, auto-TLS, domain mappings, and various knobs to control concurrency and scale traits. Eventing provides a thin abstraction on top of traditional message brokers (think Kafka or AMQP) that lets you compose your application without considering the message persistence choices in the moment (CloudEvents).\nFrom Knative Eventing, we will use two components: Broker and Trigger. A Knative Eventing Broker represents a event delivery and persistence layer, sort of an eventing mesh. A Knative Eventing Trigger works with the Broker to ask that a consumer be involved with a CloudEvent that matches some specified attributes. So the Broker is the stream of events, the Trigger is how you select events out of the stream and get them delivered.\nWith Falco producing CloudEvents, we can point our alerts from Falco at the Knative Eventing Broker. Then create a Trigger that selects the Falco event we want to react to. But we also need something to consume the event and react!\nFrom Knative Serving, we can leverage a Knative Serving Service (KService). A KService looks like a lot like a Kubernetes deployment, but it is realized on the cluster as an autoscaling and routable component without the need for manually creating additional Kubernetes Services. KService can run any container as long as it is stateless, and the lifecycle is defined only in the context of an active HTTP request.\nTo tie this up in a picture,\nFalco --[via Sidekick]--\u0026gt; Broker --[via Trigger]--\u0026gt; KService We are free to make the subscriber of the Trigger be anything we want it to be as long as it is routable from the Broker, and it accepts HTTP POSTs. The request will be a CloudEvent in Binary mode, and Falco makes JSON events, so the payload will be the standard JSON Falco is known for. In-fact, we can replace the KService in with a Kubeless function and it will work.\nDemo To demonstrate this, we have prepared a simple example: We will detect root shell creations and delete that pod.\nPrerequisites multipass Kubernetes, kubectl Helm K3s Cluster For this blog post, we a will show the demo using k3s using multipass. Here is a cluster creation commands:\nmultipass launch --name k3s-leader --cpus 2 --mem 2048M --disk 10G multipass exec k3s-leader -- /bin/bash -c \u0026#34;curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE=644 sh -\u0026#34; export K3S_IP_SERVER=\u0026#34;https://$(multipass info k3s-leader | grep \u0026#34;IPv4\u0026#34; | awk -F\u0026#39; \u0026#39; \u0026#39;{print $2}\u0026#39;):6443\u0026#34; multipass exec k3s-leader -- /bin/bash -c \u0026#34;cat /etc/rancher/k3s/k3s.yaml\u0026#34; | sed \u0026#34;s%https://127.0.0.1:6443%${K3S_IP_SERVER}%g\u0026#34; | sed \u0026#34;s/default/k3s/g\u0026#34; \u0026gt; ./k3s.yaml export KUBECONFIG=./k3s.yaml You should get this final output:\n(╯°□°)╯︵ multipass launch --name k3s-leader --cpus 2 --mem 2048M --disk 10G Launched: k3s-leader (╯°□°)╯︵ multipass exec k3s-leader -- /bin/bash -c \u0026#34;curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE=644 sh -\u0026#34; [INFO] Finding release for channel stable [INFO] Using v1.20.6+k3s1 as release [INFO] Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.20.6+k3s1/sha256sum-amd64.txt [INFO] Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.20.6+k3s1/k3s [INFO] Verifying binary download [INFO] Installing k3s to /usr/local/bin/k3s [INFO] Creating /usr/local/bin/kubectl symlink to k3s [INFO] Creating /usr/local/bin/crictl symlink to k3s [INFO] Creating /usr/local/bin/ctr symlink to k3s [INFO] Creating killall script /usr/local/bin/k3s-killall.sh [INFO] Creating uninstall script /usr/local/bin/k3s-uninstall.sh [INFO] env: Creating environment file /etc/systemd/system/k3s.service.env [INFO] systemd: Creating service file /etc/systemd/system/k3s.service [INFO] systemd: Enabling k3s unit Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service. [INFO] systemd: Starting k3s Now we have a bare bones k3s cluster!\nInstall Knative To install the rest of Knative into k3s:\n# Installs Knative Serving kubectl apply -f https://github.com/knative/serving/releases/download/v0.22.0/serving-crds.yaml kubectl wait --for=condition=Established --all crd kubectl apply -f https://github.com/knative/serving/releases/download/v0.22.0/serving-core.yaml kubectl apply -f https://github.com/knative/net-kourier/releases/download/v0.22.0/kourier.yaml kubectl patch configmap/config-network \\ --namespace knative-serving \\ --type merge \\ --patch \u0026#39;{\u0026#34;data\u0026#34;:{\u0026#34;ingress.class\u0026#34;:\u0026#34;kourier.ingress.networking.knative.dev\u0026#34;}}\u0026#39; # Installs Knative Eventing kubectl apply -f https://github.com/knative/eventing/releases/download/v0.22.0/eventing-crds.yaml kubectl wait --for=condition=Established --all crd kubectl apply -f https://github.com/knative/eventing/releases/download/v0.22.0/eventing-core.yaml kubectl apply -f https://github.com/knative/eventing/releases/download/v0.22.0/in-memory-channel.yaml kubectl apply -f https://github.com/knative/eventing/releases/download/v0.22.0/mt-channel-broker.yaml # Creates a default Broker kubectl create -f - \u0026lt;\u0026lt;EOF apiVersion: eventing.knative.dev/v1 kind: Broker metadata: name: default namespace: default EOF See also knative.dev install instructions for installing these into your own cluster.\nFalco/Falcosidekick/sidekick UI We'll use helm to install Falco ,Falcosidekick and Falcosidekick UI.\nFirst, add the falcosecurity helm repo:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts In a real project, you should get the whole chart with helm pull falcosecurity/falco --untar and then configure the values.yaml. For this tutorial, will try to keep thing as easy as possible and set configs directly by helm install command:\nhelm install falco falcosecurity/falco \\ --create-namespace --namespace falco \\ --set falcosidekick.enabled=true --set falcosidekick.webui.enabled=true \\ --set falcosidekick.config.cloudevents.address=http://broker-ingress.knative-eventing.svc.cluster.local/default/default You should get this output:\nNAME: falco LAST DEPLOYED: Thu Jan 14 23:43:46 2021 NAMESPACE: falco STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Falco agents are spinning up on each node in your cluster. After a few seconds, they are going to start monitoring your containers looking for security issues. No further action should be required. And you can see your new Falco,Falco Sidekick,Falco Sidekick UI pods:\nkubectl get pods -n falco NAME READY STATUS RESTARTS AGE falco-jh75c 1/1 Running 0 1d falco-falcosidekick-554b8859d5-v9xkg 1/1 Running 0 1d falco-falcosidekick-554b8859d5-x2zkk 1/1 Running 0 1d falco-falcosidekick-ui-5d747688f9-g96x5 1/1 Running 11 1d The arguments --set falcosidekick.enabled=true --set falcosidekick.webui.enabled=true enables Falcosidekick and the UI as the below shows:\nYou can now test it with a typical port-forwarding:\nkubectl port-forward svc/falco-falcosidekick-ui -n falco 2802:2802 Drop demo Install the demo with:\nkubectl apply -f https://github.com/n3wscott/falco-drop/releases/download/v0.1.0/release.yaml This will install a Knative Service that will consume the Falco events sent by falcosidekick (to the broker), some RBAC to enable that service to delete pods, and a Knative Trigger to register this consumer for events from the Knative Eventing Broker.\nConsumer KService The simplified go code in use is like the following:\nfunc main() { ...setup context... kc := kubeclient.Get(ctx) // Make a CloudEvents Client. c, _ := cloudevents.NewDefaultClient(p) // StartReceiver is blocking, it will deliver events to the inline function. c.StartReceiver(ctx, func(event cloudevents.Event) { // Filter based on source and type. if event.Source() == \u0026#34;falco.org\u0026#34; \u0026amp;\u0026amp; event.Type() == \u0026#34;falco.rule.output.v1\u0026#34; { // Extract the Falco event Payload payload := \u0026amp;FalcoPayload{} if err := event.DataAs(payload); err != nil { return } // Only react to \u0026#34;Terminal shell in container\u0026#34; triggered rules. if payload.Rule == \u0026#34;Terminal shell in container\u0026#34; { if err := kc.CoreV1().Pods(payload.Fields.Namespace).Delete(ctx, payload.Fields.Pod, metav1.DeleteOptions{}); err != nil { log.Println(\u0026#34;failed to delete pod from event:\u0026#34;, err) return } log.Printf(\u0026#34;[%s] deleted %s from %s because %s\\n\u0026#34;, payload.Rule, payload.Fields.Pod, payload.Fields.Namespace, payload.Output) } } }) } The full implementation can be found in the falco-drop repo.\nPro-tip: if you are developing in Go for Kubernetes, take a look at ko. ko enables containerizing go applications without needing a Dockerfile.\nEven though the Trigger only delivers events that match the Trigger filter, it is a good idea to validate the event that the function is receiving, which is why we are validating again in the above code (trust, but verify).\nEventing Triggers The Trigger configures the Broker for a subscriber to be invoked when the Broker ingresses an event that matches the spec.filter settings.\napiVersion: eventing.knative.dev/v1 kind: Trigger metadata: name: drop namespace: default spec: broker: default filter: attributes: source: falco.org type: falco.rule.output.v1 subscriber: ref: apiVersion: serving.knative.dev/v1 kind: Service name: drop Note: the kind: Service, name: drop resource is the Knative Service we created above.\nHere we are requesting that the broker only deliver events that have the attributes (CloudEvent attributes) of source=falco.org and type=falco.rule.output.v1. These events are delivered to our subscriber KService.\nWant to learn how that spec.subscriber.ref works?! It is duck typing and you can learn more, but tl;dr: it is basically doing this (except fancy),\nkubectl get ksvc drop -o jsonpath=\u0026#39;{.status.address.url}\u0026#39; Test First we will create a pod that we can execute code on later:\nkubectl run alpine --namespace default --image=alpine --restart=\u0026#39;Never\u0026#39; -- sh -c \u0026#34;sleep 600\u0026#34; You should see two pods runing, drop-00001-* and a alpine:\n(╯°□°)╯︵ kubectl get pods NAME READY STATUS RESTARTS AGE drop-00001-deployment-6b4c5d8bb-m8q4z 2/2 Running 0 4m9s alpine 1/1 Running 0 39s Next, we will execute a command in that alpine pod:\nkubectl exec -i --tty alpine --namespace default -- sh -c \u0026#34;uptime\u0026#34; The alpine pod will be terminated by the drop function once the events are processed:\n(╯°□°)╯︵ kubectl exec -i --tty alpine --namespace default -- sh -c \u0026#34;uptime\u0026#34; pod/alpine created (╯°□°)╯︵ kubectl exec -i --tty alpine --namespace default -- sh -c \u0026#34;uptime\u0026#34; 19:29:29 up 17 min, load average: 0.90, 0.85, 0.59 (╯°□°)╯︵ kubectl get pods NAME READY STATUS RESTARTS AGE drop-00001-deployment-6b4c5d8bb-m8q4z 2/2 Running 0 10m alpine 1/1 Terminating 0 5s Or simply start a hanging shell:\nkubectl run alpine-alpine --namespace default --image=alpine --restart=\u0026#39;Never\u0026#39; -- sh -c \u0026#34;sleep 600\u0026#34; kubectl exec -i --tty alpine-hang --namespace default -- sh And the shell will be closed:\n(╯°□°)╯︵ kubectl exec -i --tty alpine-hang --namespace default -- sh / # command terminated with exit code 137 The event that the drop function is reacting to is a CloudEvent that looks something like this:\nContext Attributes, specversion: 1.0 type: falco.rule.output.v1 source: falco.org id: f7628198-3822-4c98-ac3f-71770e272a16 time: 2021-01-11T23:46:19.82302759Z datacontenttype: application/json Extensions, foo: bar priority: Notice rule: Terminal shell in container Data, { \u0026#34;output\u0026#34;: \u0026#34;23:46:19.823027590: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=alpine container=f29b261f8831 shell=bash parent=runc cmdline=bash -il terminal=34816 container_id=f29b261f8831 image=mysql) k8s.ns=default k8s.pod=mysql-db-7d59548d75-wh44s container=f29b261f8831\u0026#34;, \u0026#34;priority\u0026#34;: \u0026#34;Notice\u0026#34;, \u0026#34;rule\u0026#34;: \u0026#34;Terminal shell in container\u0026#34;, \u0026#34;time\u0026#34;: \u0026#34;2021-01-11T23:46:19.82302759Z\u0026#34;, \u0026#34;output_fields\u0026#34;: { \u0026#34;container.id\u0026#34;: \u0026#34;f29b261f8831\u0026#34;, \u0026#34;container.image.repository\u0026#34;: \u0026#34;mysql\u0026#34;, \u0026#34;evt.time\u0026#34;: 1610408779823027700, \u0026#34;k8s.ns.name\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;k8s.pod.name\u0026#34;: \u0026#34;alpine\u0026#34;, \u0026#34;proc.cmdline\u0026#34;: \u0026#34;bash -il\u0026#34;, \u0026#34;proc.name\u0026#34;: \u0026#34;bash\u0026#34;, \u0026#34;proc.pname\u0026#34;: \u0026#34;runc\u0026#34;, \u0026#34;proc.tty\u0026#34;: 34816, \u0026#34;user.loginuid\u0026#34;: -1, \u0026#34;user.name\u0026#34;: \u0026#34;root\u0026#34; } } The KService consumes this event and simply deletes the pod. You can also see this activity in the falcosidekick UI.\nConclusion Thinking Cloud Native is a mindset of picking the right tool for the job and assembling these tools into something greater than their parts. Falco is a great tool for detection and alerts, it gets really interesting once we can react to those events in ways we never imagined, because integrators are creative and innovative.\nWhat will you build?\nKnative If you would like to find out more about Knative:\nGet started in knative.dev. Check out the Knative Project in GitHub. Meet the maintainers on the Knative Slack. Follow @KnativeProject on Twitter. Falco If you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project in GitHub. Get involved in the Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":["Falcosidekick","Integration"],"title":"Kubernetes Response Engine, Part 3: Falcosidekick + Knative","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-response-engine-part-3-knative/"},{"category":"blog","content":"Today we announce the spring release of Falco 0.28.1 🌱\nThis is our first patch release of Falco 0.28 that address some issues found.\nAnd this release address some security advisories\nYou can take a look at the set of changes here:\n0.28.1 As usual, in case you just want to try out the stable Falco 0.28.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nNotice that from this release onward, thanks to Jonah, one of our Falco Infra maintainers, you can find also the falco-no-driver container images on the AWS ECR gallery. Same for the the falco-driver-loader container images (link). This makes part of an effort to publish Falco container images on other registries that began while cooking up Falco 0.27.0.\nNovelties 🆕 Let's now review some of the new things Falco 0.28.1 brings.\nFor a complete list please visit the changelog.\nTo highlitght some:\nnew flag --support it includes information about the Falco engine version. new configuration field syscall_event_timeouts.max_consecutive to configure after how many consecutive timeouts without an event Falco must alert. bug fix: don't stop the webserver for Kubernetes audit logs when some invalid data arrived. Security Advisories You can check all the security advisories in the page, but the ones important for this release are:\nUndetected crash of the kernel module disables Falco Default rules can be bypassed with different techniques Security flags not enforced my CMake-files 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!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors! Falco reached 100 contributors, but also all the other Falco projects are receiving a vital amount of contributions every day.\nKeep up the good work!\nCiao!\nCarlos\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.28.1","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-28-1/"},{"category":"blog","content":" This blog post is part of a series of articles about how to create a Kubernetes response engine with Falco, Falcosidekick and a FaaS.\nSee other posts:\nKubernetes Response Engine, Part 1 : Falcosidekick + Kubeless Kubernetes Response Engine, Part 3 : Falcosidekick + Knative Kubernetes Response Engine, Part 4 : Falcosidekick + Tekton Kubernetes Response Engine, Part 5 : Falcosidekick + Argo Kubernetes Response Engine, Part 6 : Falcosidekick + Cloud Run Kubernetes Response Engine, Part 7: Falcosidekick + Cloud Functions We recently talked about a concept called \u0026quot;Kubernetes Response Engine\u0026quot;, and we achieved this by using Falco\nFalcosidekick + Kubeless. But as you might guess, Falcosidekick project is evolving day after day, which means new outputs are added. With the release 2.22.0, we are proud to support OpenFaaS as a new output for Falcosidekick. This allows us to achieve the same concept, \u0026quot;Kubernetes Response Engine\u0026quot;, but this time by using \u0026quot;OpenFaaS\u0026quot; instead of \u0026quot;Kubeless\u0026quot;. In this blog post, we will explain the basic concepts for integrating your own Response Engine into K8S with the stack Falco + Falcosidekick + OpenFaaS.\nPrerequisites We need tools with the following minimum versions to achieve this demo:\nMinikube v1.19.0 Helm v3.5.3 kubectl v1.21.0 arkade v0.7.13 faas-cli v0.13.9 Provision local Kubernetes Cluster There are various ways to provision a local Kubernetes cluster such as, KinD, k3s, k0s, Minikube etc. We are going to use Minikube in this walkthrough.\nLet's get provisioned a local Kubernetes cluster:\n$ minikube start --cpus 3 --memory 8192 --vm-driver virtualbox 😄 minikube v1.19.0 on Darwin 10.15.7 ✨ Using the virtualbox driver based on user configuration 👍 Starting control plane node minikube in cluster minikube 🔥 Creating virtualbox VM (CPUs=3, Memory=8192MB, Disk=20000MB) ... 🐳 Preparing Kubernetes v1.20.2 on Docker 20.10.4 ... ▪ Generating certificates and keys ... ▪ Booting up control plane ... ▪ Configuring RBAC rules ... 🔎 Verifying Kubernetes components... ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5 🌟 Enabled addons: storage-provisioner, default-storageclass 🏄 Done! kubectl is now configured to use \u0026#34;minikube\u0026#34; cluster and \u0026#34;default\u0026#34; namespace by default Install OpenFaaS OpenFaaS can be deployed into a variety of container orchestrators like Kubernetes, OpenShift, Docker Swarm or into a single host with faasd.\nFollow the official documentation for deploying OpenFaaS to Kubernetes.\nThe fastest option is the tool called arkade to deploy OpenFaaS:\n$ arkade install openfaas Using Kubeconfig: /Users/batuhan.apaydin/.kube/config Client: x86_64, Darwin 2021/04/10 21:39:29 User dir established as: /Users/batuhan.apaydin/.arkade/ \u0026#34;openfaas\u0026#34; already exists with the same configuration, skipping Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the \u0026#34;falcosecurity\u0026#34; chart repository ...Successfully got an update from the \u0026#34;openfaas\u0026#34; chart repository Update Complete. ⎈Happy Helming!⎈ VALUES values.yaml Command: /Users/batuhan.apaydin/.arkade/bin/helm [upgrade --install openfaas openfaas/openfaas --namespace openfaas --values /var/folders/pf/6h9t0mnd4d342ncgpjq_3zl80000gp/T/charts/openfaas/values.yaml --set queueWorker.replicas=1 --set queueWorker.maxInflight=1 --set clusterRole=false --set operator.create=false --set faasnetes.imagePullPolicy=Always --set basicAuthPlugin.replicas=1 --set gateway.replicas=1 --set gateway.directFunctions=false --set openfaasImagePullPolicy=IfNotPresent --set ingressOperator.create=false --set basic_auth=true --set serviceType=NodePort] Release \u0026#34;openfaas\u0026#34; does not exist. Installing it now. NAME: openfaas LAST DEPLOYED: Sat Apr 10 21:39:37 2021 NAMESPACE: openfaas STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: To verify that openfaas has started, run: kubectl -n openfaas get deployments -l \u0026#34;release=openfaas, app=openfaas\u0026#34; ======================================================================= = OpenFaaS has been installed. = ======================================================================= # Get the faas-cli curl -SLsf https://cli.openfaas.com | sudo sh # Forward the gateway to your machine kubectl rollout status -n openfaas deploy/gateway kubectl port-forward -n openfaas svc/gateway 8080:8080 \u0026amp; # If basic auth is enabled, you can now log into your gateway: PASSWORD=$(kubectl get secret -n openfaas basic-auth -o jsonpath=\u0026#34;{.data.basic-auth-password}\u0026#34; | base64 --decode; echo) echo -n $PASSWORD | faas-cli login --username admin --password-stdin faas-cli store deploy figlet faas-cli list # For Raspberry Pi faas-cli store list \\ --platform armhf faas-cli store deploy figlet \\ --platform armhf # Find out more at: # https://github.com/openfaas/faas Thanks for using arkade! Check if everything is working before moving onto the next step:\n$ kubectl get pods --namespace openfaas NAME READY STATUS RESTARTS AGE alertmanager-74f9b48464-7gvrj 1/1 Running 0 2m13s basic-auth-plugin-54bbd886f5-fclgn 1/1 Running 0 2m13s gateway-6f8f5d5c87-tbxns 2/2 Running 0 2m13s nats-695bf7587-hcbc2 1/1 Running 0 2m13s prometheus-577c65f58c-4nvm7 1/1 Running 0 2m13s queue-worker-b45b85966-g7kpt 1/1 Running 0 2m13s Now, it is time to deploy our function. The function we are going to deploy basically receives events for an infected pod from the Falcosidekick and deletes it immediately. Before deploying the function we need some permissions to delete Pod. We create a ServiceAccount with right to delete a Pod in any namespace, and we'll associate it to our function:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: v1 kind: ServiceAccount metadata: name: falco-pod-delete namespace: openfaas-fn --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: falco-pod-delete-cluster-role rules: - apiGroups: [\u0026#34;\u0026#34;] resources: [\u0026#34;pods\u0026#34;] verbs: [\u0026#34;get\u0026#34;, \u0026#34;list\u0026#34;, \u0026#34;delete\u0026#34;] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: falco-pod-delete-cluster-role-binding roleRef: kind: ClusterRole name: falco-pod-delete-cluster-role apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: falco-pod-delete namespace: openfaas-fn EOF Now, we are ready to deploy our falco-pod-delete function, log in into OpenFaaS Gateway first:\n$ kubectl port-forward -n openfaas svc/gateway 8080:8080 \u0026amp; $ PASSWORD=$(kubectl get secret -n openfaas basic-auth -o jsonpath=\u0026#34;{.data.basic-auth-password}\u0026#34; | base64 --decode; echo) $echo -n $PASSWORD | faas-cli login --username admin --password-stdin Calling the OpenFaaS server to validate the credentials... credentials saved for admin http://127.0.0.1:8080 Install Falco + Falcosidekick Firstly, we'll create the namespace that will host both Falco and Falcosidekick:\n$ kubectl create namespace falco We add the helm repo:\n$ helm repo add falcosecurity https://falcosecurity.github.io/charts \u0026#34;falcosecurity\u0026#34; has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the \u0026#34;falcosecurity\u0026#34; chart repository ...Successfully got an update from the \u0026#34;openfaas\u0026#34; chart repository Update Complete. ⎈Happy Helming!⎈ In a real project, you should get the whole chart with helm pull falcosecurity/falco --untar and then configure the values.yaml. For this tutorial, will try to keep thing as easy as possible and set configs directly by passing arguments to helm install command line:\n$ helm upgrade --install falco falcosecurity/falco --namespace falco \\ --set falcosidekick.enabled=true \\ --set falcosidekick.config.openfaas.functionname=\u0026#34;falco-pod-delete\u0026#34; You should get this output:\nRelease \u0026#34;falco\u0026#34; does not exist. Installing it now. NAME: falco LAST DEPLOYED: Tue Apr 13 10:49:49 2021 NAMESPACE: falco STATUS: deployed REVISION: 1 NOTES: Falco agents are spinning up on each node in your cluster. After a few seconds, they are going to start monitoring your containers looking for security issues. No further action should be required. And you can see your new Falco and Falcosidekickpods:\n$ kubectl get pods --namespace falco NAME READY STATUS RESTARTS AGE falco-falcosidekick-7779579477-mwsb4 1/1 Running 0 67s falco-falcosidekick-7779579477-n5v89 1/1 Running 0 67s falco-p97rw 1/1 Running 0 67s The argument falcosidekick.enabled=true sets the following settings in Falco for you:\n--set falco.jsonOutput=true \\ --set falco.httpOutput.enabled=true \\ --set falco.httpOutput.url=http://falco-falcosidekick:2801 The arguments --set falco.jsonOutput=true --set falco.httpOutput.enabled=true --set falco.httpOutput.url=http://falco-falcosidekick:2801 are there to configure the format of events and the URL where Falco will send them. As Falco and Falcosidekick will be in the same namespace, it can directly use the name of the service (falco-falcosidekick) above Falcosidekick pods.\nWe check the logs:\n$ kubectl logs deployment/falco-falcosidekick -n falco Found 2 pods, using pod/falcosidekick-5c696d7fd8-9bnnj 2021/04/10 19:21:55 [INFO] : Enabled Outputs : [OpenFaaS] 2021/04/10 19:21:55 [INFO] : Falco Sidekick is up and listening on :2801 OpenFaaS is displayed as enabled output, everything is good 👍.\nInstall our OpenFaaS function Our really basic function will receive events from Falco thanks to Falcosidekick, check if the triggered rule is * Terminal Shell in container* , extract the namespace and pod name from the fields of events and delete the according pod:\nBasically, the process is:\n+----------+ +---------------+ +----------+ | Falco +-----------------\u0026gt; Falcosidekick +--------------------\u0026gt; OpenFaaS | +----^-----+ sends event +---------------+ triggers +-----+----+ | | detects a shell | | | | +----+-------+ deletes | | Pwned Pod \u0026lt;----------------------------------------------------------+ +------------+ Let's create the function and deploy it:\n$ faas-cli template store pull golang-middleware Fetch templates from repository: https://github.com/openfaas/golang-http-template at 2021/04/10 21:56:34 Attempting to expand templates from https://github.com/openfaas/golang-http-template 2021/04/10 21:56:35 Fetched 2 template(s) : [golang-http golang-middleware] from https://github.com/openfaas/golang-http-template $ tree -L 2 . . └── template ├── golang-http └── golang-middleware\nDon't forget to set your docker id in the prefix section, mine is devopps. $ faas-cli new falco-pod-delete --lang golang-middleware --prefix devopps faas-cli new falco-pod-delete --lang golang-middleware --prefix devopps Folder: falco-pod-delete created.\n/ _ \\ _ __ ___ _ __ | | _ __ / | | | | | ' \\ / _ \\ ' | | / |/ _ _ | || | |) | / | | | | (| | (| |) | _/| ./ ___|| ||| _,|_,|__/ ||\nFunction created in folder: falco-pod-delete Stack file written: falco-pod-delete.yml\nNotes: You have created a new function which uses Golang 1.13.\nTo include third-party dependencies, use Go modules and use \u0026quot;--build-arg GO111MODULE=on\u0026quot; with faas-cli build or configure this via your stack.yml file.\nSee more: https://docs.openfaas.com/cli/templates/ For detailed examples: https://github.com/openfaas-incubator/golang-http-template\n$ tree -L 2 . . ├── falco-pod-delete │ └── handler.go ├── falco-pod-delete.yml └── template ├── golang-http └── golang-middleware First, replace the falco-pod-delete.yml with the following content:\nversion: 1.0 provider: name: openfaas gateway: http://127.0.0.1:8080 functions: falco-pod-delete: lang: golang-middleware handler: ./falco-pod-delete image: devopps/falco-pod-delete:latest # be careful this line, it should be your docker id. annotations: com.openfaas.serviceaccount: falco-pod-delete build_args: GO111MODULE: on Once you have edited it, let's continue with the code, create a go.mod.\n$ cd falco-pod-delete $ go mod init falco-pod-delete go: creating new go.mod: module falco-pod-delete go: to add module requirements and sums: go mod tidy Then, replace the handler.go with the following content:\npackage function import ( \u0026#34;context\u0026#34; \u0026#34;encoding/json\u0026#34; \u0026#34;io/ioutil\u0026#34; \u0026#34;log\u0026#34; \u0026#34;net/http\u0026#34; \u0026#34;time\u0026#34; metaV1 \u0026#34;k8s.io/apimachinery/pkg/apis/meta/v1\u0026#34; \u0026#34;k8s.io/client-go/kubernetes\u0026#34; \u0026#34;k8s.io/client-go/rest\u0026#34; ) var kubeClient *kubernetes.Clientset func init() { // creates the in-cluster config config, err := rest.InClusterConfig() if err != nil { panic(err.Error()) } // creates the clientset kubeClient, err = kubernetes.NewForConfig(config) if err != nil { panic(err.Error()) } } type Alert struct { Output string `json:\u0026#34;output\u0026#34;` Priority string `json:\u0026#34;priority\u0026#34;` Rule string `json:\u0026#34;rule\u0026#34;` Time time.Time `json:\u0026#34;time\u0026#34;` OutputFields struct { ContainerID string `json:\u0026#34;container.id\u0026#34;` ContainerImageRepository interface{} `json:\u0026#34;container.image.repository\u0026#34;` ContainerImageTag interface{} `json:\u0026#34;container.image.tag\u0026#34;` EvtTime int64 `json:\u0026#34;evt.time\u0026#34;` FdName string `json:\u0026#34;fd.name\u0026#34;` K8SNsName string `json:\u0026#34;k8s.ns.name\u0026#34;` K8SPodName string `json:\u0026#34;k8s.pod.name\u0026#34;` ProcCmdline string `json:\u0026#34;proc.cmdline\u0026#34;` } `json:\u0026#34;output_fields\u0026#34;` } var CriticalNamespaces = []string{\u0026#34;kube-system\u0026#34;, \u0026#34;kube-public\u0026#34;, \u0026#34;kube-node-lease\u0026#34;, \u0026#34;falco\u0026#34;, \u0026#34;openfaas\u0026#34;, \u0026#34;openfaas-fn\u0026#34;} func Handle(w http.ResponseWriter, r *http.Request) { var alert Alert if r.Body != nil { defer r.Body.Close() body, _ := ioutil.ReadAll(r.Body) json.Unmarshal(body, \u0026amp;alert) podName := alert.OutputFields.K8SPodName namespace := alert.OutputFields.K8SNsName var critical bool for _ , ns := range CriticalNamespaces { if ns == namespace { critical = true break } } if !critical { log.Printf(\u0026#34;Deleting pod %s from namespace %s\u0026#34;, podName, namespace) kubeClient.CoreV1().Pods(namespace).Delete(context.Background(), podName, metaV1.DeleteOptions{}) } } w.WriteHeader(http.StatusOK) w.Write([]byte(\u0026#34;OK\u0026#34;)) } After that, update your Go Modules by doing go mod tidy:\n$ go mod tidy go: finding module for package k8s.io/client-go/rest go: finding module for package k8s.io/apimachinery/pkg/apis/meta/v1 go: finding module for package k8s.io/client-go/kubernetes go: downloading k8s.io/client-go v0.21.0 go: downloading k8s.io/apimachinery v0.21.0 go: found k8s.io/apimachinery/pkg/apis/meta/v1 in k8s.io/apimachinery v0.21.0 go: found k8s.io/client-go/kubernetes in k8s.io/client-go v0.21.0 go: found k8s.io/client-go/rest in k8s.io/client-go v0.21.0 go: downloading k8s.io/api v0.21.0 go: downloading golang.org/x/net v0.0.0-20210224082022-3d97a244fca7 go: downloading sigs.k8s.io/structured-merge-diff/v4 v4.1.0 go: downloading golang.org/x/term v0.0.0-20210220032956-6a3ed077a48d Now, you should be able to build, push and deploy your function with faas-cli:\n$ cd .. $ faas-cli up -f falco-pod-delete.yml [0] \u0026gt; Building falco-pod-delete. Clearing temporary build folder: ./build/falco-pod-delete/ Preparing: ./falco-pod-delete/ build/falco-pod-delete/function Building: devopps/falco-pod-delete:latest with golang-middleware template. Please wait.. #1 [internal] load build definition from Dockerfile #1 sha256:8cd765381aabb90df3bcfbc06f4d175af37d66b85125d463585abc1fc878b94b #1 transferring dockerfile: 1.81kB done #1 DONE 0.0s ... Use \u0026#39;docker scan\u0026#39; to run Snyk tests against images to find vulnerabilities and learn how to fix them Image: devopps/falco-pod-delete:latest built. [0] \u0026lt; Building falco-pod-delete done in 1.31s. [0] Worker done. Total build time: 1.31s [0] \u0026gt; Pushing falco-pod-delete [devopps/falco-pod-delete:latest]. The push refers to repository [docker.io/devopps/falco-pod-delete] 8096edd09fbc: Layer already exists 464d68aca3d9: Layer already exists e4766ea46ad0: Layer already exists 5f70bf18a086: Layer already exists a823d50a5b72: Layer already exists 060f21486264: Layer already exists 8ea3b23f387b: Layer already exists latest: digest: sha256:f94abba203232b97cb2873ef5d60eec31b52d492f3d3ee106d6a9877bf131d95 size: 1782 [0] \u0026lt; Pushing falco-pod-delete [devopps/falco-pod-delete:latest] done. [0] Worker done. Deploying: falco-pod-delete. Deployed. 202 Accepted. URL: http://127.0.0.1:8080/function/falco-pod-delete Check if everything is working before moving to the next step:\n$ kubectl get pods --namespace openfaas-fn NAME READY STATUS RESTARTS AGE falco-pod-delete-7dc9f5fbb8-gbfk7 1/1 Running 0 27s Test our function We start by creating a dumb pod:\n$ kubectl run alpine --namespace default --image=alpine --restart=\u0026#39;Never\u0026#39; -- sh -c \u0026#34;sleep 600\u0026#34; pod/alpine created $ kubectl get pods --namespace default AME READY STATUS RESTARTS AGE alpine 1/1 Running 0 11s Let's run a shell command inside and see what happens:\n$ kubectl exec -i --tty alpine --namespace default -- sh -c \u0026#34;uptime\u0026#34; 19:27:21 up 50 min, load average: 0.11, 0.12, 0.11 As expected we got the result of our command, but, if we get the status of the pod we retrieve:\n$ kubectl get pods --namespace default NAME READY STATUS RESTARTS AGE alpine 1/1 Terminating 0 103s 💥 It has been terminated 💥\nWe can now check the logs of components.\nFor Falco:\n$ kubectl logs daemonset/falco --namespace falco .. {\u0026#34;output\u0026#34;:\u0026#34;19:27:21.002873265: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=alpine container=97c9868ea832 shell=sh parent=runc cmdline=sh -c uptime terminal=34816 container_id=97c9868ea832 image=alpine) k8s.ns=default k8s.pod=alpine container=97c9868ea832\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Notice\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Terminal shell in container\u0026#34;,\u0026#34;time\u0026#34;:\u0026#34;2021-04-10T19:27:21.002873265Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;container.id\u0026#34;:\u0026#34;97c9868ea832\u0026#34;,\u0026#34;container.image.repository\u0026#34;:\u0026#34;alpine\u0026#34;,\u0026#34;evt.time\u0026#34;:1618082841002873265,\u0026#34;k8s.ns.name\u0026#34;:\u0026#34;default\u0026#34;,\u0026#34;k8s.pod.name\u0026#34;:\u0026#34;alpine\u0026#34;,\u0026#34;proc.cmdline\u0026#34;:\u0026#34;sh -c uptime\u0026#34;,\u0026#34;proc.name\u0026#34;:\u0026#34;sh\u0026#34;,\u0026#34;proc.pname\u0026#34;:\u0026#34;runc\u0026#34;,\u0026#34;proc.tty\u0026#34;:34816,\u0026#34;user.loginuid\u0026#34;:-1,\u0026#34;user.name\u0026#34;:\u0026#34;root\u0026#34;}} {\u0026#34;output\u0026#34;:\u0026#34;19:27:21.038853452: Notice Unexpected connection to K8s API Server from container (command=handler k8s.ns=openfaas-fn k8s.pod=falco-pod-delete-7dc9f5fbb8-gbfk7 container=12fc4de5ccc3 image=devopps/falco-pod-delete:latest connection=172.17.0.9:43812-\u0026gt;10.96.0.1:443) k8s.ns=openfaas-fn k8s.pod=falco-pod-delete-7dc9f5fbb8-gbfk7 container=12fc4de5ccc3\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Notice\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Contact K8S API Server From Container\u0026#34;,\u0026#34;time\u0026#34;:\u0026#34;2021-04-10T19:27:21.038853452Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;container.id\u0026#34;:\u0026#34;12fc4de5ccc3\u0026#34;,\u0026#34;container.image.repository\u0026#34;:\u0026#34;devopps/falco-pod-delete\u0026#34;,\u0026#34;container.image.tag\u0026#34;:\u0026#34;latest\u0026#34;,\u0026#34;evt.time\u0026#34;:1618082841038853452,\u0026#34;fd.name\u0026#34;:\u0026#34;172.17.0.9:43812-\u0026gt;10.96.0.1:443\u0026#34;,\u0026#34;k8s.ns.name\u0026#34;:\u0026#34;openfaas-fn\u0026#34;,\u0026#34;k8s.pod.name\u0026#34;:\u0026#34;falco-pod-delete-7dc9f5fbb8-gbfk7\u0026#34;,\u0026#34;proc.cmdline\u0026#34;:\u0026#34;handler\u0026#34;}} For Falcosidekick:\n$ kubectl logs deployment/falcosidekick --namespace falco 2021/04/10 19:27:21 [INFO] : OpenFaas - Post OK (200) 2021/04/10 19:27:21 [INFO] : OpenFaas - Function Response : OK 2021/04/10 19:27:21 [INFO] : OpenFaas - Call Function \u0026#34;falco-pod-delete.openfaas-fn\u0026#34; OK .. For falco-delete-pod function:\n$ faas-cli logs -f --name falco-pod-delete 2021/04/10 19:34:03 Deleting pod alpine from namespace default 2021/04/10 19:34:03 POST / - 200 OK - ContentLength: 2 Conclusion With this really simple example, we only scratched the surface of possibilities, so don't hesitate to share with us on Slack (https://kubernetes.slack.com #falco) your comments, ideas and successes. You're also always welcome to contribute.\n","summary":"","tags":["Falcosidekick","Integration"],"title":"Kubernetes Response Engine, Part 2: Falcosidekick + OpenFaas","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-response-engine-part-2-openfaas/"},{"category":"blog","content":"Today we announce the spring release of Falco 0.28.0 🌱\nThis is the second release of Falco during 2021!\nYou can take a look at the set of changes here:\n0.28.0 As usual, in case you just want to try out the stable Falco 0.28.0, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the container images? No problem at all! 🐳\nYou can read more about running Falco with Docker in the docs.\nNotice that from this release onward, thanks to Jonah, one of our Falco Infra maintainers, you can find also the falco-no-driver container images on the AWS ECR gallery. Same for the the falco-driver-loader container images (link). This makes part of an effort to publish Falco container images on other registries that began while cooking up Falco 0.27.0.\nNovelties 🆕 Let's now review some of the new things Falco 0.28.0 brings.\nFor a complete list please visit the changelog.\nBreaking changes Before we dive into anything it's important to notice that this release introduces some breaking changes.\nSince bintray is sunsetting 🌇, all the Falco packages, for all the officially supported distros, will be published at https://download.falco.org from now on.\nWe already moved the package repositories and the previous Falco versions (both development, starting from Falco 0.26.1 onward, and all the stable versions, starting with Falco 0.20.0).\nSo you can start using the new package repositories just now! Here's a step-by-step guide to upgrade your Falco repository settings. 📄\nDo not use the Falco Bintray repositories anymore, please. ⚠️\nNotice also that the DEB and RPM packages use now systemd ⚫◀️ in place of the previous init.d service units.\nAnother change worth mentioning is that we definitely removed the SKIP_MODULE_LOAD environment variable used by the Falco container image to skip the driver loading. It was deprecated with Falco 0.24.0. If you're still using is please switch to use the new environment variable named SKIP_DRIVER_LOADER. ⏭️\nExceptions As announced, the support for structured rules exceptions has been merged in. ✔️\nIt's a mechanism to define additional conditions that when matched cause the Falco engine to do not emit the relative Falco alert.\nYou can read more about such a feature in the document proposing it.\nNotice that the default Falco rulesets are not using the exceptions at the moment, but you can surely write your own Falco rules using this feature if it suits your needs.\nHealthz Thanks to Carlos, the Falco Kubernetes web server exposes now a /healthz endpoint.\nIt can be used to check whether Falco is up and running. It's a feature requested by the users of Falco Helm charts to improve them.\nFalco driver loader The Falco driver loader, a bunch of bash doing magic things when a Falco container starts, will first try to detect and download a prebuilt Falco driver for the current host (current list of prebuild drivers is available here), and only then it will try to compile a working Falco driver on the fly.\nWe decided to invert such logic because we have 4K+ prebuilt drivers and a mechanism to update them as soon new distro and new kernels born.\nThis way, the boot time of Falco containers should improve by a lot in the majority of cases, avoiding compiling a Falco driver for your host if we already built one for you.\nTunable drops The syscall_event_drops configuration item inside falco.yaml gains a new child (threshold) that you can use to tune the noisiness of the drops.\nIt represents a percentage, thus you might provide a value between 0 and 1 for it. By default it's 0.1, feel free to experiment with it in case you need to.\nEverything else Engine fixes A bug in the Falco engine, and precisely in the Falco rules language, preventing numbers to be parsed properly has been finally fixed.\nAlso, another bug regarding how the missing values (NA) were handled in multi-value fields (eg., lists) is now fixed and no more present.\nRules As usual, our community is awesome at improving the Falco rules!\nThis release brings a bunch of improvements to various macros, lists, and rules. Take a look at the changelog (rules section) for details about them.\nThree 3️⃣ new rules, Debugfs Launched in Privileged Container, and Mount Launched in Privileged Container, and Sudo Potential Privilege Escalation (very useful to promptly alert you about CVE-2021-3156) have also been introduced.\nWhat's next 🔮 We have a scheduled 0.28.1 release on May 4th 2021!\nAs usual, the final release date will be discussed during the Falco Community Calls.\nAs always, we are going to have bug fixes and improvements.\nLet'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!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors! Falco reached 100 contributors, but also all the other Falco projects are receiving a vital amount of contributions every day.\nKeep up the good work!\nBye!\nLeo\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.28.0 a.k.a. Falco 2021.04","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-28-0/"},{"category":"blog","content":"Foreword This article is, like my previous article about OpenEBS and NFS Server Provisioner, a hands-on guide on how to install, configure and monitor your existing cluster with Falco.\nBackground Kubernetes is a great technology and brings many possibilities but also more complexity. To get more involved with Kubernetes, my company decided to setup an internal bare-metal cluster. This cluster should be a platform to earn practice in a cloud-native environment. While there are no plans to run any production workloads soon, we want to enforce different kinds of rules to work as secure as possible from the very beginning.\nWe are working in multiple cross-functional teams and most developers have never used Kubernetes before. They are familiar with YAML as a configuration language from various projects and tools and have some docker experience.\nRequirement analysis For security, there is no tool that can do everything. So, we have different layers to consider. One of these considerations is Kyverno. With this tool, we can define rules to prevent insecure configurations like hostpath volumes with access to sensitive files. We can also enforce configurations like resource requests and limits for deployments and pods. This helps for manifests but there are still things left. We also want to use third party applications and manifests like Helm charts. So, we must be sure that third parties and our own apps don't misbehave. We want to monitor behavior to have an overview of what is happening in our cluster and be able to react if we detect any bad things. When we have more information, we can investigate how we can prevent it with existing tools like additional Kyverno Policies or additional tooling.\nFalco From many different sources I heard about the open source project Falco. Falco describes itself as the de facto Kubernetes threat detection engine. It uses system calls, kernel events, and additional sources like Kubernetes Audit Events to monitor the runtime behavior of an entire cluster on different levels like sensitive access on nodes or single containers. It uses YAML files to define its detection rules. So, we don't have to learn any additional configuration language. Falco ships with a large set of predefined rules, provided by and maintained by the open source community, which covers a large part of our needs. Beyond our requirement furthermore, it brings support for detecting scenarios like insecure use of configmaps for credentials.\nDecisions It is possible to install Falco as DeamonSet with a provided Helm Chart. The recommended way is to install Falco as kernel module directly on the nodes. As kernel module, it is outside the scope of Kubernetes and it is not possible to disable or remove it with cluster access. We will install it directly on the nodes, so it is not affected by any cluster misbehavior.\nWe need to configure the cluster to send Kubernetes Audit Events to Falco and be able to monitor both our cluster and the nodes themselves.\nFalco provides several output formats to send or persist all found rule violations. Falcosidekick from the Falco ecosystem uses the http_output from Falco to spread the output to many different tools like Loki, Kibana, or Slack. We are using Loki to aggregate our logs and monitor them with Grafana provided by Rancher's Monitoring Stack. So, we will be using Falcosidekick to send Falco rule violations to Loki.\nEnvironment Multi Node Cluster hosted on Hetzner Cloud Ubuntu 20.04 Operating System Bare Metal RKE Cluster managed with Rancher v2.5.5 and Kubernetes v1.19.6 Getting started with Falco Installing Falco I follow the official installation instruction for Ubuntu from the Falco Documentation. This must be done on all nodes in the cluster.\nAdding the Falco repository:\ncurl -s https://falco.org/repo/falcosecurity-packages.asc | apt-key add - echo \u0026#34;deb https://download.falco.org/packages/deb stable main\u0026#34; | tee -a /etc/apt/sources.list.d/falcosecurity.list apt-get update -y The next step should be to install the kernel headers for the current kernel version with:\napt-get -y install linux-headers-$(uname -r) I encountered a problem with this step because for the kernel version on my node Linux 5.4.0-29-generic no linux-headers package existed. I solved it with a kernel upgrade to Linux 5.11.0-051100rc6-generic with the help of this Article: https://sypalo.com/how-to-upgrade-ubuntu.\nI upgraded only the Kernel without the Ubuntu part.\nIf you don't have any issues with installing the linux-headers package, you can skip these steps\nDownload the kernel files.\ncd /tmp wget -c https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11-rc7/amd64/linux-headers-5.11.0-051100rc7_5.11.0-051100rc7.202102072330_all.deb wget -c https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11-rc7/amd64/linux-headers-5.11.0-051100rc7-generic_5.11.0-051100rc7.202102072330_amd64.deb wget -c https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11-rc7/amd64/linux-image-unsigned-5.11.0-051100rc7-generic_5.11.0-051100rc7.202102072330_amd64.deb wget -c https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11-rc7/amd64/linux-modules-5.11.0-051100rc7-generic_5.11.0-051100rc7.202102072330_amd64.deb Install the new kernel version and reboot the node.\nsudo dpkg -i *.deb sudo shutdown -r now Check if the upgrade succeeded.\nuname -rs Linux 5.11.0-051100rc6-generic Now I was able to install Falco.\napt-get install -y falco The last installation step is to start Falco as service.\nservice falco start Let's check if it works as expected:\njournalctl -fu falco -- Logs begin at Sat 2021-02-13 08:15:49 CET. -- Feb 13 20:33:09 node-1 falco[19438]: Sat Feb 13 20:33:09 2021: Falco initialized with configuration file /etc/falco/falco.yaml Feb 13 20:33:09 node-1 falco[19438]: Sat Feb 13 20:33:09 2021: Loading rules from file /etc/falco/falco_rules.yaml: Feb 13 20:33:09 node-1 falco[19459]: Falco initialized with configuration file /etc/falco/falco.yaml Feb 13 20:33:09 node-1 falco[19459]: Loading rules from file /etc/falco/falco_rules.yaml: Feb 13 20:33:09 node-1 falco[19459]: Loading rules from file /etc/falco/falco_rules.local.yaml: Feb 13 20:33:09 node-1 falco[19438]: Sat Feb 13 20:33:09 2021: Loading rules from file /etc/falco/falco_rules.local.yaml: Feb 13 20:33:09 node-1 falco[19459]: Loading rules from file /etc/falco/k8s_audit_rules.yaml: Feb 13 20:33:09 node-1 falco[19438]: Sat Feb 13 20:33:09 2021: Loading rules from file /etc/falco/k8s_audit_rules.yaml: Feb 13 20:33:10 node-1 systemd[1]: Started LSB: Falco syscall activity monitoring agent. Feb 13 20:33:10 node-1 falco[19460]: Starting internal webserver, listening on port 8765 Depending on your node it can already track a rule violation like my zsh file access.\nFeb 13 20:33:20 node-1 falco[19460]: 20:33:20.106330811: Error File below / or /root opened for writing (user=root user_loginuid=0 command=zsh parent=sshd file=/root/.zsh_history program=zsh container_id=host image=\u0026lt;NA\u0026gt;) Feb 13 20:33:20 node-1 falco[19460]: 20:33:20.106511423: Warning Shell history had been deleted or renamed (user=root user_loginuid=0 type=unlink command=zsh fd.name=\u0026lt;NA\u0026gt; name=\u0026lt;NA\u0026gt; path=/root/.zsh_history.LOCK oldpath=\u0026lt;NA\u0026gt; host (id=host)) The provided default rules are defined in /etc/falco/falco_rules.yaml. Each rule can be overwritten by creating a rule with the same name in /etc/falco/falco_rules.local.yaml. You can also create you own custom rules in the same file.\nConfigure RKE to send Kubernetes Audit Events Falco ships with a set of default rules for Kubernet Audit Events. These rules are located in /etc/falco/k8s_audit_rules.yaml. To use them I have to configure the RKE kube-apiserver container with a corresponding Audit Policy and Webhook configuration. Both files are provided from the Falco evolution repository.\nThe next steps must be done on all nodes within the cluster.\nI created a separate folder on each node and store the configuration files.\nmkdir -m 0755 /etc/falco/apiserver cd /etc/falco/apiserver curl https://raw.githubusercontent.com/falcosecurity/evolution/master/examples/k8s_audit_config/audit-policy.yaml -o audit-policy.yaml curl https://raw.githubusercontent.com/falcosecurity/evolution/master/examples/k8s_audit_config/webhook-config.yaml.in -o webhook-config.yaml Now I have to change the $FALCO_SERVICE_CLUSTERIP in the webhook-config.yaml. Because falco runs on the host OS and the kube-apiserver runs with networkmode host, the container can access the falco webserver on localhost.\napiVersion: v1 kind: Config clusters: - name: falco cluster: server: http://localhost:8765/k8s-audit contexts: - context: cluster: falco user: \u0026#34;\u0026#34; name: default-context current-context: default-context preferences: {} users: [] The kube-apiserver can be configured by updating the RKE cluster.yaml. If the RKE cluster was created with the rke CLI tool the file is on your local machine. I created this cluster with Rancher, so I can update the cluster.yaml in the Rancher Cluster Manager UI. Select your cluster and click on Edit in the Menu. Click on Edit as YAML to update your kube-apiserver.\nUpdate the kube-apiserver configuration in a RKE CLI based cluster.yaml under services.kube-api, for a cluster.yaml created by Rancher under rancher_kubernetes_engine_config.services.kube-api. I mount the falco configuration files with the extra_binds property into the kube-apiserver and add them as extra_args to the API Server.\n# cluster.yaml created by Rancher # this snipped includes only the changeset rancher_kubernetes_engine_config: services: kube-api: # This WILL OVERRIDE any existing defaults extra_args: audit-policy-file: /etc/falco/audit-policy.yaml audit-webhook-config-file: /etc/falco/webhook-config.yaml delete-collection-workers: \u0026#39;3\u0026#39; # prevent changes to already existing default value extra_binds: - \u0026#39;/etc/falco/apiserver:/etc/falco\u0026#39; Save the cluster.yaml in the Rancher UI or use rke up, depending on your cluster. The changes will be applied and the kube-apiserver should be started successfully.\nTry it out To be sure the Kubernetes Audit Events are sent to Falco, I will trigger one of the Falco Kubernetes rules. I create a ConfigMap with an aws_access_key_id key which triggers the Create/Modify Configmap With Private Credentials rule.\nkubectl create configmap credentials --from-literal aws_access_key_id=super-secret On only one of the cluster master nodes should be a new entry.\nFeb 13 23:08:49 node-1 falco[539986]: 23:08:49.288822016: Warning K8s configmap with private credential (user=system:serviceaccount:cattle-system:kontainer-engine verb=create configmap=credentials config={\\\u0026#34;aws_access_key_id\\\u0026#34;:\\\u0026#34;super-secret\\\u0026#34;}) First Result Falco is installed and running on all cluster nodes. The provided configuration and rules are in place and it created its first alerts based on them. On top of that RKE is configured to send Kubernetes Audit Events. This additional event source gives Falco the possibility to monitor the whole cluster and its workloads.\nCentralize Falco Alerts with Falcosidekick While Falco is up and running on all nodes there is no central place for an overview of all rule violations. Because Falco is installed on the host there is no access point within the cluster. To solve this problem I will use Falcosidekick. Each Falco service will send its alerts to a centralized Falcosidekick application which will provide different targets to monitor them.\nI'm using the provided Helm Chart from the Falco community to install it. As workload in the cluster, I can send the alerts to the internal cluster Monitoring.\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update I install Falcosidekick with the new Falcosidekick UI. This UI provides a simple way to verify if my configuration works.\nhelm install falcosidekick falcosecurity/falcosidekick --set webui.enabled=true --namespace falcosidekick --create-namespace Check if Falcosidekick and Falcosidekick UI are up and running.\nkubectl get pod,service -n falcosidekick NAME READY STATUS RESTARTS AGE pod/falcosidekick-5f44cb5bff-s974v 1/1 Running 0 39s pod/falcosidekick-5f44cb5bff-z8jmz 1/1 Running 0 39s pod/falcosidekick-ui-867f5d6f7-26hp6 1/1 Running 0 39s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/falcosidekick ClusterIP 10.43.103.143 \u0026lt;none\u0026gt; 2801/TCP 39s service/falcosidekick-ui ClusterIP 10.43.129.135 \u0026lt;none\u0026gt; 2802/TCP 39s The next step is to configure the Falco service on all nodes to send its alerts to Falcosidekick. So, I connect on each node and update the configuration file /etc/falco/falco.yaml to send the alerts in JSON format over HTTP to the given ClusterIP.\n# /etc/falco/falco.yaml # this snipped includes only the changeset json_output: true json_include_output_property: true http_output: enabled: true url: \u0026#34;http://10.43.103.143:2801/\u0026#34; # use your ClusterIP for falcosidekick instead After updating the Falco configuration, you have to restart the service service falco restart.\nLet's use the Falcosidekick UI which I installed together with Falcosidekick.\nkubectl port-forward service/falcosidekick-ui 2802:2802 I already see notice events because kubectl port-forward triggers a Falco rule.\nSecond Result The first step was to install and configure Falco as well as the cluster. But there was no easy way to see if it worked and I have to check the alerts on each node. With the integration of Falcosidekick and the new Falcosidekick UI, I have a centralized place to view the alerts and verify that everything is working as expected.\nMonitoring with Loki and Grafana The Falcosidekick UI is a good starting point but not suitable for long time Monitoring and custom evaluations.\nI will use Loki because I'm already using it as a log aggregator for my workloads. It is not part of the default Monitoring Stack from Rancher, so I had to install it on my own.\nRequirements Rancher v2.5 or above to use the new Monitoring Stack Rancher Monitoring is installed and working Installing Loki Loki is available as Helm Chart. There are multiple Options you can choose from. In the scope of this article Loki as standalone service is enough. I am using the Loki Stack to install Loki together with Promtail. Promtail is a tool which will send the logs from all my workloads to Loki. So, Loki becomes my general log aggregation solution for my cluster.\nhelm repo add grafana https://grafana.github.io/helm-charts helm repo update Loki and Promtail are enabled by default in this chart. I don't install any other optional application from it.\nhelm install loki grafana/loki-stack --namespace=loki-stack --create-namespace Let's check if it was installed successfully.\nkubectl get pods,services -n loki-stack NAME READY STATUS RESTARTS AGE loki-0 1/1 Running 0 1m43s loki-promtail-ldf2n 1/1 Running 0 1m43s loki-promtail-lx2s6 1/1 Running 0 1m43s loki-promtail-skm8m 1/1 Running 0 1m43s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE loki ClusterIP 10.43.84.52 \u0026lt;none\u0026gt; 3100/TCP 1m43s loki-headless ClusterIP None \u0026lt;none\u0026gt; 3100/TCP 1m43s To use Loki in the provided Grafana from the Monitoring Stack, I must add Loki as additional data source.\nYou have to be authenticated and have the required Admin role in Grafana.\nClick \u0026quot;Add data source\u0026quot; and select \u0026quot;Loki\u0026quot; under \u0026quot;Logging \u0026amp; document databases\u0026quot;.\nNow I must configure Loki by setting the URL to my Loki service. Because it is running in a separate namespace, I have to use the full qualified service URL http://loki.loki-stack.svc.cluster.local:3100. I don't configure anything else. It is not accessible from the outside world and so I have no additional authentication configured.\nI can verify that it is working by using the Grafana Explore View to search for logs from Loki itself. It's possible that this only works when the loki-stack was installed.\nTo configure Falcosidekick to use Loki as a output target, I add additional values to the Falcosidekick Helm installation.\nhelm upgrade falcosidekick falcosecurity/falcosidekick --set config.loki.hostport=http://loki.loki-stack.svc.cluster.local:3100 --set config.customfields=\u0026#34;source:falco\u0026#34; --set webui.enabled=true --namespace falcosidekick I updated the Loki hostport configuration to the Loki service inside of the cluster. I also added a custom field to be able to query all logs from Falco in Grafana.\nTo verify that the configuration works, I will trigger Falco by reusing the example with an aws_access_key_id key in a ConfigMap.\nkubectl create configmap aws-credentials --from-literal aws_access_key_id=super-secret I'm using the custom field to query all Falco alerts within Grafana.\nConclusion It takes several steps to get everything up and running but we get a big security and monitoring improvement too. We can monitor how our, as well as third party applications behave at runtime and if they do any unexpected bad action. We can improve our security over time by adding our own custom rules or change existing rules to our needs. With Falcosidekick we are flexible enough to add more additional channels to get early feedback for special kinds of alerts. With Loki and Grafana we can create Dashboards to have a much better overview. As a little cherry on the cake, we not only enabled Falco alerts for Grafana, with Loki and Promtail together we installed a general logging solution for all our cluster workloads.\nIf you have any feedback feel free to contact me on Twitter @FrankJogeleit.\nThis article was published on CodeYourWorld.\nSpecial Thanks to the Falco Community While I did my first steps with Falco, I encountered a few small problems. To solve these issues, I joined the falco community in the official Kubernetes Slack Workspace and they helped me a lot. I fixed a documentation issue. The Maintainer and I found and fixed a bug in Falcosidekick which causes problems when sending Kubernetes Audit Events to Loki and we finalized the first version of the Falcosidekick UI. At the end of my experiment, I not only have a running runtime monitoring, but I'm also an official contributor to the Falcosidekick- and Falcosidekick UI Project.\nGet involved If you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project on GitHub. Get involved Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. ","summary":"","tags":null,"title":"Falco Security and Monitoring on RKE Bare Metal Cluster with Rancher","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-on-rke-with-rancher/"},{"category":"blog","content":" We are excited to announce the contribution from Sysdig Inc. of the kernel module, the eBPF probe, and the libraries to the Cloud Native Computing Foundation. The source code of these components has been moved into the Falco organization. You can already find it in the falcosecurity/libs repository.\nThis contribution is an initial - yet fundamental - part of a broader process outlined in a proposal that the Falco Authors presented and discussed with the Falco community during the past months.\nAs you all already know, Falco mainly operates on top of a data source: system calls. This data source is collected using either a kernel module or an eBPF probe, which we call drivers. The two drivers are equivalent in functionality. On the performance side, the kernel module is a tiny bit more efficient, while the eBPF approach is safer and more modern. Before being consumed by Falco, the collected data needs to be enriched (for example, a file descriptor number needs to be converted into a file name or an IP address). The enrichment is accomplished by two libraries: libsinsp and libscap.\nFuture plans In the coming months, we planned to make these components even more awesome and consumable by the community.\nImprove the build mechanism by modernizing the CMake files Define a SemVer 2.0 versioning mechanism Implement a robust test suite Setup Continuous Integrations jobs through our beautiful Falco Prow Infra Distribute these libraries as packages for major distros, hosting them on download.falco.org Document the API As you can see, there is a lot to do! New opportunities for contributions 😄\nHow to migrate existing pull requests In case you have on-going pull requests against draios/sysdig regarding these components, we provide the following instructions to move them to falcosecurity/libs repository.\nAssuming you already have a fork of https://github.com/falcosecurity/libs and a fork of https://github.com/draios/sysdig under your GitHub handle, and assuming they are in sync with their respective upstreams:\nClone your falcosecurity/libs fork locally:\ngit clone https://github.com/\u0026lt;your_handle\u0026gt;/libs cd libs Add the a remote for your draios/sysdig fork:\ngit remote add sysdig-fork https://github.com/\u0026lt;username\u0026gt;/sysdig.git git fetch --all Checkout your pull request's branch:\ngit checkout --no-track -b \u0026lt;branch\u0026gt; sysdig-fork/\u0026lt;branch\u0026gt; Rebase it on top the master branch:\ngit rebase -i --exec \u0026#39;git commit --amend --no-edit -n -s -S\u0026#39; master Then, push it to your \u0026lt;your_handle\u0026gt;/libs repository:\ngit push -u origin \u0026lt;branch\u0026gt; You are now all set to open a PR on https://github.com/falcosecurity/libs. As usual, you can do that manually from the GitHub user interface.\nConclusions The contribution of such fantastic software will help not only Falco but also other projects to have a more secure Cloud-Native environment. More information about this contribution is in Loris Degioanni’s CNCF blog post.\nAside from Falco, also the sysdig cli-tool was refactored to use these libraries. From now on, also other projects can benefit from them! We are thrilled to see what folks will build upon these libraries!\nIf you would like to find out more about Falco:\nCheck out the Falco project in GitHub Get involved in the Falco community Meet the maintainers on the #falco channel (Kubernetes Slack) Follow @falco_org on Twitter ","summary":"","tags":null,"title":"Contribution of the drivers and the libraries","url":"https://v0-43--falcosecurity.netlify.app/blog/contribution-drivers-kmod-ebpf-libraries/"},{"category":"blog","content":"Special Thanks to Leonardo Grasso for assisting me\nAgenda The agenda of this document is to share the experience and explain the steps followed for the performance testing of Falco application deployed using helm chart on a Kubernetes cluster and establish a relation between the resources (CPU and Memory) required by Falco and the number of syscall per second it can handle.\nAssumptions The assumptions for the performance testing are as below:\nKnown events are the syscalls that will match the Falco rule and trigger an alert\nUnknown events are the syscalls that will be discarded by Falco as they will not meet any condition in Falco rules\nThe load of unknown events should be minimum during the Falco performance testing i.e. other activities on the host should be restricted to minimum\nThe performance testing is done by Falco event-generator tool benchmark feature\nThe Falco event-generator benchmark generates syscall events only, so there are no events of type k8s-audit during this benchmarking exercise\nPlease, keep in mind that not all actions can be used for benchmarking since some of them take too long to generate a high number of EPS. For example, k8saudit actions are not supposed to work, since those actions need some time to create Kubernetes resources. Also, some syscall actions sleep for a while (like the syscall.ReadSensitiveFileUntrusted) thus cannot be used.\nEPS (Event Per Second) number of events generated by event-generator in a single round. It doesn't corresponds to a syscall but the event here is a combination of multiple syscalls e.g. if the action targets a rule that's triggered when a file is created under /bin , the action will probably use 3 syscall:\nOne to check the directory\nOne to create the file under /bin\nFinally the last one to delete the file\nHowever the event-generator counts only 1 event per action\nINFO statistics cpu=\u0026#34;38.1%\u0026#34; lost=\u0026#34;2%\u0026#34; res_mem=\u0026#34;38 MB\u0026#34; throughput=\u0026#34;4371.6 EPS\u0026#34; virt_mem=\u0026#34;1.1 GB\u0026#34; Falco receive a lot of events but not all of those trigger a rule so the drop stats produced by the Falco process refers to the raw numbers of syscall received (Falco does not know if those syscall could match a rule, since it lost them). On the other hand, the event-generator knows exactly which events it has generated, so can say for sure: I had sent 100 and I received 50 back, thus 50% are lost\nNo Custom rules considered during performance testing, only default Falco rules are triggered\nOnly tested the benchmarking feature with three types of actions ChangeThreadNamespace|ReadSensitiveFileUntrusted|WriteBelowBinaryDir\nThe event-generator round prior to the round where drops were seen in the Falco logs was considered to calculate the number of syscall supported at a particular resource setup\nFalco Fun Facts:\nHere are some facts about Falco that might come to your mind during performance testing.\nFalco just read one event a time from the buffer, process it and the discard it Falco receive a lot of events but not all of those trigger a rule Falco it's just designed to have a low memory consumption and the memory is not strictly related to the EPS, since each events are processed one-by-one (so once an event is processed, it's then discarded and the memory is freed) Steps Setup\nFalco was deployed with -s option and --stats-interval set to 1 sec in order to capture the total syscalls by Falco per second\n-s \u0026lt;stats_file\u0026gt; If specified, append statistics related to Falco\u0026#39;s reading/processing of events\rto this file (only useful in live mode).\r--stats-interval \u0026lt;msec\u0026gt; When using -s \u0026lt;stats_file\u0026gt;, write statistics every \u0026lt;msec\u0026gt; ms.\rThis uses signals, so don\u0026#39;t recommend intervals below 200 ms.\rDefaults to 5000 (5 seconds). Sample Configuration:\n# Changes in Falco daemonset\rspec:\rcontainers:\r- args:\r- /usr/bin/falco\r- -s\r- /var/log/falco.txt\r- --stats-interval\r- \u0026#34;1000\u0026#34;\r- --cri\r- /run/containerd/containerd.sock\r- -K\r- /var/run/secrets/kubernetes.io/serviceaccount/token\r- -k\r- https://$(KUBERNETES_SERVICE_HOST)\r- -pk Enable the gRPC and relaxed the rate-limiter in the Falco configuration by making the below changes in the values.yaml\ngrpc:\renabled: true\rthreadiness: 0\r# gRPC unix socket with no authentication\runixSocketPath: \u0026amp;#34;unix:///run/falco/falco.sock\u0026amp;#34;\r# gRPC over the network (mTLS) / required when unixSocketPath is empty\rlistenPort: 5060\rprivateKey: \u0026amp;#34;/etc/falco/certs/server.key\u0026amp;#34;\rcertChain: \u0026amp;#34;/etc/falco/certs/server.crt\u0026amp;#34;\rrootCerts: \u0026amp;#34;/etc/falco/certs/ca.crt\u0026amp;#34;\rgRPC output service. By default it is off. By enabling this all the output events will be kept in memory until you read them with a gRPC client. Make sure to have a consumer for them or leave this disabled. grpcOutput: enabled: true # A throttling mechanism implemented as a token bucket limits the\nrate of Falco notifications. This throttling is controlled by the following configuration options: - rate: the number of tokens (i.e. right to send a notification) gained per second. Defaults to 1. - max_burst: the maximum number of tokens outstanding. Defaults to 1000. With these defaults, Falco could send up to 1000 notifications after an initial quiet period, and then up to 1 notification per second afterward. It would gain the full burst back after 1000 seconds of no activity. outputs: rate: \u0026quot;1000000000\u0026quot; maxBurst: \u0026quot;1000000000\u0026quot; Download the event-generator binary from here. Extract the binary and use command event-generator list to list the sample events this tool generate\nRun event-generator using the bench option with below command\nevent-generator bench \u0026#34;ChangeThreadNamespace|ReadSensitiveFileUntrusted|WriteBelowBinaryDir\u0026#34; --loop --pid $(ps -ef | awk \u0026#39;$8==\u0026#34;falco\u0026#34; {print $2}\u0026#39;) event-generator bench Benchmark for Falco\nSynopsis Benchmark a running Falco instance.\nThis command generates a high number of Event Per Second (EPS), to test the events throughput allowed by Falco. The number of EPS is controlled by the \u0026quot;--sleep\u0026quot; option: reduce the sleeping duration to increase the EPS. If the \u0026quot;--loop\u0026quot; option is set, the sleeping duration is halved on each round. The \u0026quot;--pid\u0026quot; option can be used to monitor the Falco process.\nN.B.: - the Falco gRPC Output must be enabled to use this command - \u0026quot;outputs.rate\u0026quot; and \u0026quot;outputs.max_burst\u0026quot; values within the Falco configuration must be increased, otherwise EPS will be rate-limited by the throttling mechanism - since not all actions can be used for benchmarking, only those actions matching the given regular expression are used\nOne common way to use this command is as following:\nevent-generator bench \u0026#34;ChangeThreadNamespace|ReadSensitiveFileUntrusted\u0026#34; --loop --sleep 10ms --pid $(pidof -s falco) Warning: This command might alter your system. For example, some actions modify files and directories below /bin, /etc, /dev, etc. Make sure you fully understand what is the purpose of this tool before running any action.\nevent-generator bench [regexp] [flags] Options --all Run all actions, including those disabled by default\r--as string Username to impersonate for the operation\r--as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups.\r--cache-dir string Default HTTP cache directory (default \u0026#34;$HOME/.kube/http-cache\u0026#34;)\r--certificate-authority string Path to a cert file for the certificate authority\r--client-certificate string Path to a client certificate file for TLS\r--client-key string Path to a client key file for TLS\r--cluster string The name of the kubeconfig cluster to use\r--context string The name of the kubeconfig context to use\r--grpc-ca string CA root file path for connecting to a Falco gRPC server (default \u0026#34;/etc/falco/certs/ca.crt\u0026#34;)\r--grpc-cert string Cert file path for connecting to a Falco gRPC server (default \u0026#34;/etc/falco/certs/client.crt\u0026#34;)\r--grpc-hostname string Hostname for connecting to a Falco gRPC server (default \u0026#34;localhost\u0026#34;)\r--grpc-key string Key file path for connecting to a Falco gRPC server (default \u0026#34;/etc/falco/certs/client.key\u0026#34;)\r--grpc-port uint16 Port for connecting to a Falco gRPC server (default 5060)\r--grpc-unix-socket string Unix socket path for connecting to a Falco gRPC server (default \u0026#34;unix:///run/falco/falco.sock\u0026#34;)\r-h, --help help for bench\r--humanize Humanize values when printing statistics (default true)\r--insecure-skip-tls-verify If true, the server\u0026#39;s certificate will not be checked for validity. This will make your HTTPS connections insecure\r--kubeconfig string Path to the kubeconfig file to use for CLI requests.\r--loop Run in a loop\r--match-server-version Require server version to match client version\r-n, --namespace string If present, the namespace scope for this CLI request (default \u0026#34;default\u0026#34;)\r--pid int A process PID to monitor while benchmarking (e.g. the falco process)\r--polling-interval duration Duration of gRPC APIs polling timeout (default 100ms)\r--request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don\u0026#39;t timeout requests. (default \u0026#34;0\u0026#34;)\r--round-duration duration Duration of a benchmark round (default 5s)\r-s, --server string The address and port of the Kubernetes API server\r--sleep duration The length of time to wait before running an action. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means no sleep. (default 100ms)\r--token string Bearer token for authentication to the API server\r--user string The name of the kubeconfig user to use Options inherited from parent commands -c, --config string Config file path (default $HOME/.falco-event-generator.yaml if exists)\r--logformat string available formats: \u0026#34;text\u0026#34; or \u0026#34;json\u0026#34; (default \u0026#34;text\u0026#34;)\r-l, --loglevel string Log level (default \u0026#34;info\u0026#34;) Execution\nMonitor the number of syscall per second on the servers where Falco is deployed. In the below sample output the values in the \u0026quot;cur\u0026quot; sections shows the cumulative total values whereas the values in the \u0026quot;delta\u0026quot; sections represents the values for that particular instance\nFalco syscall logs:\n{\u0026#34;sample\u0026#34;: 2961, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 46226792, \u0026#34;drops\u0026#34;: 86992, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 10700, \u0026#34;drops\u0026#34;: 0, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 0},\r{\u0026#34;sample\u0026#34;: 2962, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 46323843, \u0026#34;drops\u0026#34;: 86992, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 97051, \u0026#34;drops\u0026#34;: 0, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 0},\r{\u0026#34;sample\u0026#34;: 2963, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 46696561, \u0026#34;drops\u0026#34;: 86992, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 372718, \u0026#34;drops\u0026#34;: 0, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 0},\r{\u0026#34;sample\u0026#34;: 2964, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 47069599, \u0026#34;drops\u0026#34;: 86992, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 373038, \u0026#34;drops\u0026#34;: 0, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 0},\r{\u0026#34;sample\u0026#34;: 2965, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 47419658, \u0026#34;drops\u0026#34;: 86992, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 350059, \u0026#34;drops\u0026#34;: 0, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 0},\r{\u0026#34;sample\u0026#34;: 2966, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 47784238, \u0026#34;drops\u0026#34;: 86992, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 364580, \u0026#34;drops\u0026#34;: 0, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 0},\r{\u0026#34;sample\u0026#34;: 2967, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 48134675, \u0026#34;drops\u0026#34;: 102975, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 350437, \u0026#34;drops\u0026#34;: 15983, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 4.56088},\r{\u0026#34;sample\u0026#34;: 2968, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 48311955, \u0026#34;drops\u0026#34;: 131484, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 177280, \u0026#34;drops\u0026#34;: 28509, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 16.0813},\r{\u0026#34;sample\u0026#34;: 2969, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 48323039, \u0026#34;drops\u0026#34;: 131484, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 11084, \u0026#34;drops\u0026#34;: 0, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 0},\r{\u0026#34;sample\u0026#34;: 2970, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 48333847, \u0026#34;drops\u0026#34;: 131484, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 10808, \u0026#34;drops\u0026#34;: 0, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 0},\r{\u0026#34;sample\u0026#34;: 2971, \u0026#34;cur\u0026#34;: {\u0026#34;events\u0026#34;: 48342737, \u0026#34;drops\u0026#34;: 131484, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;delta\u0026#34;: {\u0026#34;events\u0026#34;: 8890, \u0026#34;drops\u0026#34;: 0, \u0026#34;preemptions\u0026#34;: 0}, \u0026#34;drop_pct\u0026#34;: 0} This way you can get the syscall activity on you servers in idle mode and can use it as a reference. Also you can check if there are any drops happening prior to starting the event-generator\nStart the event-generator tool and observer the statistics printed by it for every round and parallelly monitory the number of syscalls per second in the Falco syscall output.\nThe event-generator cycle: In every round it generates a load at certain rate (EPS) then rests, during this time it calculates the statistics for that previous round and in the resting time the sycalls also drop. In the next round it doubles the rate and same cycle is repeated till it is stopped.\nevent-generator logs:\nINFO round #14 sleep=\u0026#34;12.207µs\u0026#34;\rINFO resting...\rINFO syscall.ReadSensitiveFileUntrusted actual=14224 expected=14458 ratio=0.9838151888227971\rINFO syscall.WriteBelowBinaryDir actual=14219 expected=14456 ratio=0.9836054233536248\rINFO syscall.ChangeThreadNamespace actual=14208 expected=14457 ratio=0.9827765096493049\rINFO statistics cpu=\u0026#34;68.0%\u0026#34; lost=\u0026#34;1%\u0026#34; res_mem=\u0026#34;36 MB\u0026#34; throughput=\u0026#34;8674.2 EPS\u0026#34; virt_mem=\u0026#34;1.1 GB\u0026#34;\rINFO\rINFO round #15 sleep=\u0026#34;6.103µs\u0026#34;\rINFO resting...\rINFO syscall.ReadSensitiveFileUntrusted actual=15093 expected=16962 ratio=0.8898125221082419\rINFO syscall.WriteBelowBinaryDir actual=15080 expected=16963 ratio=0.8889936921535105\rINFO syscall.ChangeThreadNamespace actual=15058 expected=16961 ratio=0.8878014268026649\rINFO statistics cpu=\u0026#34;72.6%\u0026#34; lost=\u0026#34;11%\u0026#34; res_mem=\u0026#34;36 MB\u0026#34; throughput=\u0026#34;10177.2 EPS\u0026#34; virt_mem=\u0026#34;1.1 GB\u0026#34; The instance you see values in drops in the \u0026quot;delta\u0026quot; section (sample 2967 in the Falco syscall logs above) stop the event-generator tool and capture the values of the event-generator round prior to it (The drops occured in round #15 as seen in the event generator statistics above, so we will consider the values for round #14)\nThe total syscall supported by Falco at the given resource setting can then be calculated by taking the average of the syscall values in instances (in sample 2963, 2964, 2965 and 2966) prior to the instance where drop occurred. The instances (sample 2961 and 2962 ) with low syscall are for the resting period in the event-generator cycle\nObservations The observation here are just for the reference purpose only and the intention of this document is to illustrate a process for Falco performance testing, it is highly recommended to carry out the performance testing on your environment and use this data for reference purpose only. The environment under test is a kubernetes cluster deployed over VM hosted on openstack\nCPU Memory Number of syscalls per second EPS (rounded to lower limit) 500m(0.5) 512 Mi Upto 150K 2800 1 512 Mi Upto 250K 4200 2 512 Mi Upto 320K 7000 Important points:\nAdding/removing the type of event in event generator will have impact on the EPS but the total syscall value should still be around the same range\nIf the EPS gets stuck at certain range then review the type of events used in the event generator to generate the syscall load as the event generator runs action sequentially (single-threaded), so the total time it takes in a loop is the sum of the time needed to execute all the three events so if one of those is slow, the whole loop will be slow. And when the sleeping time reaches 0, the event-generator EPS cannot grow more since all the time in the loop is just the actions' execution, Thus resulting in EPS toggling in certain range and not increasing with every round\nExample:\nIn the below example the EPS was not increasing at the rate at which it was supposed to but rather went down in one round. This is an indication that one of the event ChangeThreadNamespace|ReadSensitiveFileUntrusted|WriteBelowBinaryDir was causing the event generator to slow down. In this case it was WriteBelowBinaryDir as the server had I/O issue on the root disk. After the problematic event WriteBelowBinaryDir was removed from the list it worked fine\n#event-generator bench \u0026#34;ChangeThreadNamespace|ReadSensitiveFileUntrusted|WriteBelowBinaryDir\u0026#34; --loop --grpc-unix-socket=unix:///var/run/falco/falco.sock --pid \u0026lt;Falco PID\u0026gt;\rINFO round #12 sleep=\u0026quot;97.656µs\u0026quot; INFO resting... INFO syscall.WriteBelowBinaryDir actual=1696 expected=1696 ratio=1 INFO syscall.ChangeThreadNamespace actual=1695 expected=1695 ratio=1 INFO syscall.ReadSensitiveFileUntrusted actual=1696 expected=1696 ratio=1 INFO statistics cpu=\u0026quot;21.9%\u0026quot; lost=\u0026quot;0%\u0026quot; res_mem=\u0026quot;121 MB\u0026quot; throughput=\u0026quot;1017.4 EPS\u0026quot; virt_mem=\u0026quot;1.5 GB\u0026quot; INFO INFO round #13 sleep=\u0026quot;48.828µs\u0026quot; INFO resting... INFO syscall.WriteBelowBinaryDir actual=1787 expected=1787 ratio=1 INFO syscall.ChangeThreadNamespace actual=1788 expected=1788 ratio=1 INFO syscall.ReadSensitiveFileUntrusted actual=1786 expected=1786 ratio=1 INFO statistics cpu=\u0026quot;23.6%\u0026quot; lost=\u0026quot;0%\u0026quot; res_mem=\u0026quot;121 MB\u0026quot; throughput=\u0026quot;1072.2 EPS\u0026quot; virt_mem=\u0026quot;1.5 GB\u0026quot; INFO INFO round #14 sleep=\u0026quot;24.414µs\u0026quot; INFO resting... INFO syscall.WriteBelowBinaryDir actual=1614 expected=1614 ratio=1 INFO syscall.ChangeThreadNamespace actual=1613 expected=1613 ratio=1 INFO syscall.ReadSensitiveFileUntrusted actual=1615 expected=1615 ratio=1 INFO statistics cpu=\u0026quot;22.4%\u0026quot; lost=\u0026quot;0%\u0026quot; res_mem=\u0026quot;121 MB\u0026quot; throughput=\u0026quot;968.4 EPS\u0026quot; virt_mem=\u0026quot;1.5 GB\u0026quot; ","summary":"","tags":null,"title":"Falco Performance Testing","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-performance-testing/"},{"category":"blog","content":"One of the upcoming features in Falco 0.28.0 is support for exceptions in rules. Exceptions are a concise way to represent conditions under which a rule should not generate an alert. Here's a quick example:\n- rule: Write below binary dir ... exceptions: - name: known_bin_writers fields: [proc.name, fd.name] comps: [=, contains] values: - [nginx, /usr/bin/nginx] - [apache, /bin/apache] ... This rule defines an exception known_bin_writers, using fields proc.name and fd.name, and lists combinations of processes and file paths that are allowed to write to binary directories.\nWhy Are Exceptions Useful? Currently, most rules have additional condition snippets of the form and not ... that define exceptions e.g. conditions user which the rule should not generate an alert.\nThe rule with the most exceptions is Write below etc via the macro write_etc_common. Prior to these changes, it had ~90 exceptions to track various programs and paths below /etc! Each exception was expressed as its own top-level macro:\n- macro: write_etc_common condition: \u0026gt; etc_dir and evt.dir = \u0026lt; and open_write ... and not sed_temporary_file and not exe_running_docker_save and not ansible_running_python and not python_running_denyhosts and not fluentd_writing_conf_files and not user_known_write_etc_conditions and not run_by_centrify and not run_by_adclient and not qualys_writing_conf_files and not git_writing_nssdb and not plesk_writing_keys and not plesk_install_writing_apache_conf and not plesk_running_mktemp and not networkmanager_writing_resolv_conf and not run_by_chef and not add_shell_writing_shells_tmp and not duply_writing_exclude_files and not xmlcatalog_writing_files and not parent_supervise_running_multilog and not supervise_writing_status and not pki_realm_writing_realms and not htpasswd_writing_passwd and not lvprogs_writing_conf and not ovsdb_writing_openvswitch and not datadog_writing_conf and not curl_writing_pki_db\t... This polluted the top-level set of objects with a bunch of one-off macros only used by a single rule.\nProblems with Appends/Overrides to Define Exceptions Although the concepts of macros and lists in condition fields, combined with appending to lists/conditions in macros/rules, is very general purpose, it can be unwieldy:\nAppending to conditions can result in incorrect behavior, unless the original condition has its logical operators set up properly with parentheses. For example: rule: my_rule condition: (evt.type=open and (fd.name=/tmp/foo or fd.name=/tmp/bar)) rule: my_rule condition: or fd.name=/tmp/baz append: true Results in unintended behavior. It will match any fd related event where the name is /tmp/baz, when the intent was probably to add /tmp/baz as an additional opened file.\nA good convention many rules use is to have a clause \u0026quot;and not user_known_xxxx\u0026quot; built into the condition field. However, it's not in all rules and its use is a bit haphazard.\nAppends and overrides can get confusing if you try to apply them multiple times. For example:\nmacro: allowed_files condition: fd.name=/tmp/foo ... macro: allowed_files condition: and fd.name=/tmp/bar append: true If someone wanted to override the original behavior of allowed_files, they would have to use append: false in a third definition of allowed_files, but this would result in losing the append: true override.\nExceptions Syntax Starting in 0.28.0, falco supports an optional exceptions property to rules. The exceptions property value is a list of identifier, list of tuples of filtercheck fields, and optional comparison operators and field values. Here's an example:\n- rule: Write below binary dir desc: an attempt to write to any file below a set of binary directories condition: \u0026gt; bin_dir and evt.dir = \u0026lt; and open_write and not package_mgmt_procs and not exe_running_docker_save and not python_running_get_pip and not python_running_ms_oms and not user_known_write_below_binary_dir_activities exceptions: - name: proc_writer fields: [proc.name, fd.directory] - name: container_writer fields: [container.image.repository, fd.directory] comps: [=, startswith] - name: proc_filenames fields: [proc.name, fd.name] comps: [=, in] - name: filenames fields: fd.filename comps: in This rule defines four kinds of exceptions:\nproc_writer: uses a combination of proc.name and fd.directory container_writer: uses a combination of container.image.repository and fd.directory proc_filenames: uses a combination of process and list of filenames. filenames: uses a list of filenames The specific strings \u0026quot;proc_writer\u0026quot;/\u0026quot;container_writer\u0026quot;/\u0026quot;proc_filenames\u0026quot;/\u0026quot;filenames\u0026quot; are arbitrary strings and don't have a special meaning to the rules file parser. They're only used to link together the list of field names with the list of field values that exist in the exception object.\nproc_writer does not have any comps property, so the fields are directly compared to values using the = operator. container_writer does have a comps property, so each field will be compared to the corresponding exception items using the corresponding comparison operator.\nproc_filenames uses the in comparison operator, so the corresponding values entry should be a list of filenames.\nfilenames differs from the others in that it names a single field and single comp operator. In this case, all values are combined into a single list.\nNotice that exception fields and comparison operators are defined as a part of the rule. This is important because the author of the rule defines what construes a valid exception to the rule. In this case, an exception can consist of a process and file directory (actor and target), but not a process name only (too broad).\nException values may also be defined as a part of a rule, but in many cases values will be defined in rules with append: true. Here's an example:\n- list: apt_files items: [/bin/ls, /bin/rm] - rule: Write below binary dir exceptions: - name: proc_writer values: - [apk, /usr/lib/alpine] - [npm, /usr/node/bin] - name: container_writer values: - [docker.io/alpine, /usr/libexec/alpine] - name: proc_filenames values: - [apt, apt_files] - [rpm, [/bin/cp, /bin/pwd]] - name: filenames values: [python, go] append: true This appended version of Write below binary dir defines tuples of field values, with the exception name used to link the filtercheck fields and values. A rule exception applies if for a given event, the fields in a rule.exception match all of the values in some exception.item. For example, if a program apk writes to a file below /usr/lib/alpine, the rule will not trigger, even if the condition is met.\nNotice that an item in a values list can be a list. This allows building exceptions with operators like \u0026quot;in\u0026quot;, \u0026quot;pmatch\u0026quot;, etc. that work on a list of items. The item can also be a name of an existing list. If not present surrounding parantheses will be added.\nFinally, note that the structure of the values property differs between the items where fields is a list of fields (proc_writer/container_writer/proc_filenames) and when it is a single field (procs_only). This changes how the exceptions are folded into the rule's condition.\nRules Updated To Use Exceptions Along with this code change, we've also revamped the rules to migrate as many rules as possible to use exceptions instead of one-off macros. We've kept the original ad-hoc \u0026quot;customization' macros e.g. user_known_update_package_registry, user_known_write_below_binary_dir_activities, etc. so if you had already added exceptions in the form of appends/overrides of these macros, those exceptions will continue to work. Please consider using exceptions whenever possible to customize the behavior of existing rules, and please define exceptions fields when creating your own rules.\nLearn More We have a more complete description of how exceptions work in the documentation along with best practices for adding exceptions to rules. You can also read the original proposal describes the benefits of exceptions in more detail.\nIn case you prefer to just try them out please notice you need Falco 0.27.0-15+8c4040b (deb, rpm, tarball).\n","summary":"","tags":null,"title":"Falco Rules Now Support Exceptions","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-rules-now-support-exceptions/"},{"category":"blog","content":"Today we announce the release of Falco 0.27.0 🥳\nThis is the first release of 2021!\nYou can take a look at the set of changes here:\n0.27.0 As usual, in case you just want to try out the stable Falco 0.27.0, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the docker images? No problem!\nYou can read more about running Falco with Docker in the docs.\nImportant Falco 0.27.0 is the first release that has the container images released also on Amazon ECR. This is not officially supported yet and we are only releasing the falcosecurity/falco image there right now. Thanks to @leodido and @jonahjon!\nWhat's new? This is not a complete list, for a complete list visit the changelog.\nBreaking changes Before we dive into anything it's important to notice that this Falco release introduces one BREAKING CHANGE. If you rely on running Falco without any configuration file you can't do that anymore. All the official installation methods ships with a default configuration file with them.\nPerformance notes The mechanism that handles Falco outputs has been completely rewritten in C++ (Thanks @leogr). Before this release, Falco relied on a mix of Lua and C++ API calls that led to a lot of crosstalk between the engine and the outputs mechanisms. Having a single C++ implementation helps a lot in reducing the crosstalk issue.\nSince Lua is gone for the outputs now, the only reason that prevented us from having multi-threaded outputs is also gone. Outputs in Falco 0.27.0 are able to use multiple threads and also have a mechanism to detect when an output is too slow.\nAn output is \u0026quot;too slow\u0026quot; when it does not allow to deliver an alert within a given deadline, Falco will give an alert from the \u0026quot;internal\u0026quot; data source complaining about that. The default timeout is 200 milliseconds. It can be configured using the output_timeout configuration in falco.yaml.\nEverything else! New website As you can notice, we have a new website! Raji and Lore are the two behind this new restyle with the help of @leogr and @leodido. This new website features a new design, a search bar and a nice dropdown you can use to navigate old Falco releases (Falco 0.26 and 0.27 are the only ones available now).\ngRPC changes The Falco gRPC version service now also exposes the Falco engine version.\nRules changes\nWe have 15 rules changes in this release! As always, our community values the quality of the rules as their top priority. Keeping a sane set of default rules for everyone to benefit is very important for us!\nWhat's next? We have a scheduled 0.28.0 release on March 18th 2021!\nAs always, we are going to have bug fixes and improvements.\nA feature that is announced to go to 0.28.0 will be the support for structured rules exceptions, a way to define conditions to exclude certain alerts from happening when the exception happens.\nYou can read @mstemm's proposal here.\nMoreover, we are very close to releasing ARM (armv7 and aarch64 builds) of Falco within the next releases. Lore worked on PR#1442 to port Falco to those architectures and Jonahjon is working to make our infrastructure support for building, testing and releasing for those as well.\nLet'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!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors! Keep up the good vibes!\nBye!\nLore\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.27.0 a.k.a. \"The happy 2021 release\"","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-27-0/"},{"category":"blog","content":" This blog post is part of a series of articles about how to create a Kubernetes response engine with Falco, Falcosidekick and a FaaS.\nSee other posts:\nKubernetes Response Engine, Part 2 : Falcosidekick + OpenFaas Kubernetes Response Engine, Part 3 : Falcosidekick + Knative Kubernetes Response Engine, Part 4 : Falcosidekick + Tekton Kubernetes Response Engine, Part 5 : Falcosidekick + Argo Kubernetes Response Engine, Part 6 : Falcosidekick + Cloud Run Kubernetes Response Engine, Part 7: Falcosidekick + Cloud Functions Two years ago, we presented to you a Kubernetes Response Engine based on Falco. The idea was to trigger Kubeless serverless functions for deleting infected pod, start a Sysdig capture or forward the events to GCP PubSub. See the README.\nTo avoid maintaining this custom stack, we worked hard with the community to integrate all components into Falcosidekick and to improve the UX. With the last release 2.20.0 we have the finale piece, the integration of Kubeless as native output. More details in our retrospective of 2020.\nIn this blog post, we will explain the basic concepts for integrating your own Response Engine into K8S with the stack Falco + Falcosidekick + Kubeless.\nRequirements We require a kubernetes cluster running at least 1.17 release and helm and kubectl installed.\nInstall Kubeless Follow the official quick start page:\nexport RELEASE=$(curl -s https://api.github.com/repos/kubeless/kubeless/releases/latest | grep tag_name | cut -d \u0026#39;\u0026#34;\u0026#39; -f 4) kubectl create ns kubeless kubectl create -f https://github.com/kubeless/kubeless/releases/download/$RELEASE/kubeless-$RELEASE.yaml After a few seconds, we can check that the controller is up and running:\nkubectl get pods -n kubeless NAME READY STATUS RESTARTS AGE kubeless-controller-manager-99459cb67-tb99d 3/3 Running 3 2m34s Install Falco Firstly, we'll create the namespace that will use both Falco and Falcosidekick:\nkubectl create ns falco Add the helm repo:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts In a real project, you should get the whole chart with helm pull falcosecurity/falco --untar and then configure the values.yaml. For this tutorial, we will try to keep things as easy as possible and set configs directly by helm install command:\nhelm install falco falcosecurity/falco --set falco.jsonOutput=true --set falco.httpOutput.enabled=true --set falco.httpOutput.url=http://falcosidekick:2801 -n falco You should get this output:\nNAME: falco LAST DEPLOYED: Thu Jan 14 23:43:46 2021 NAMESPACE: falco STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Falco agents are spinning up on each node in your cluster. After a few seconds, they are going to start monitoring your containers looking for security issues. No further action should be required. And you can see your new Falco pods:\nkubectl get pods -n falco NAME READY STATUS RESTARTS AGE falco-ctmzg 1/1 Running 0 111s falco-sfnn8 1/1 Running 0 111s falco-rrg28 1/1 Running 0 111s The arguments --set falco.jsonOutput=true --set falco.httpOutput.enabled=true --set falco.httpOutput.url=http://falcosidekick:2801 are there configuring the format of events and the URL where Falco will send them. As Falco and Falcosidekick will be in the same namespace, we can directly use the name of the service (falcosidekick).\nInstall Falcosidekick The process is quite the same:\nhelm install falcosidekick falcosecurity/falcosidekick --set config.kubeless.namespace=kubeless --set config.kubeless.function=delete-pod -n falco You should get this output:\nNAME: falcosidekick LAST DEPLOYED: Thu Jan 14 23:55:12 2021 NAMESPACE: falco STATUS: deployed REVISION: 1 NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace falco -l \u0026#34;app.kubernetes.io/name=falcosidekick,app.kubernetes.io/instance=falcosidekick\u0026#34; -o jsonpath=\u0026#34;{.items[0].metadata.name}\u0026#34;) kubectl port-forward $POD_NAME 2801:2801 echo \u0026#34;Visit http://127.0.0.1:2801 to use your application\u0026#34; We check the logs:\nkubectl logs deployment/falcosidekick -n falco 2021/01/14 22:55:31 [INFO] : Enabled Outputs : Kubeless 2021/01/14 22:55:31 [INFO] : Falco Sidekick is up and listening on port 2801 Kubeless is displayed as enabled output, everything is good 👍.\nThat's it, we really tried to get a nice UX 😉.\nInstall our Kubeless function We'll not explain how to write or how to work Kubeless functions, please read the official docs for more information.\nOur basic function will receive events from Falco, thanks to Falcosidekick. Check if the triggered rule is Terminal Shell in container. See rule, extract the namespace and pod name from fields of events, and delete the according pod:\nfrom kubernetes import client,config config.load_incluster_config() def delete_pod(event, context): rule = event[\u0026#39;data\u0026#39;][\u0026#39;rule\u0026#39;] or None output_fields = event[\u0026#39;data\u0026#39;][\u0026#39;output_fields\u0026#39;] or None if rule and rule == \u0026#34;Terminal shell in container\u0026#34; and output_fields: if output_fields[\u0026#39;k8s.ns.name\u0026#39;] and output_fields[\u0026#39;k8s.pod.name\u0026#39;]: pod = output_fields[\u0026#39;k8s.pod.name\u0026#39;] namespace = output_fields[\u0026#39;k8s.ns.name\u0026#39;] print (f\u0026#34;Deleting pod \\\u0026#34;{pod}\\\u0026#34; in namespace \\\u0026#34;{namespace}\\\u0026#34;\u0026#34;) client.CoreV1Api().delete_namespaced_pod(name=pod, namespace=namespace, body=client.V1DeleteOptions()) Basically, the process is:\n+----------+ +---------------+ +----------+ | Falco +-----------------\u0026gt; Falcosidekick +--------------------\u0026gt; Kubeless | +----^-----+ sends event +---------------+ triggers +-----+----+ | | detects a shell | | | | +----+-------+ deletes | | Pwned Pod \u0026lt;----------------------------------------------------------+ +------------+ Before deploying our function, we need to create a ServiceAccount for it, as it will need the right to delete a pod in any namespace:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -n kubeless -f - apiVersion: v1 kind: ServiceAccount metadata: name: falco-pod-delete --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: falco-pod-delete-cluster-role rules: - apiGroups: [\u0026#34;\u0026#34;] resources: [\u0026#34;pods\u0026#34;] verbs: [\u0026#34;get\u0026#34;, \u0026#34;list\u0026#34;, \u0026#34;delete\u0026#34;] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: falco-pod-delete-cluster-role-binding roleRef: kind: ClusterRole name: falco-pod-delete-cluster-role apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: falco-pod-delete namespace: kubeless EOF namespace: kubelessetetion.k8s.io serviceaccount/falco-pod-delete created clusterrole.rbac.authorization.k8s.io/falco-pod-delete-cluster-role created clusterrolebinding.rbac.authorization.k8s.io/falco-pod-delete-cluster-role-binding created Only remains the installation of our function itself:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -n kubeless -f - apiVersion: kubeless.io/v1beta1 kind: Function metadata: finalizers: - kubeless.io/function generation: 1 labels: created-by: kubeless function: delete-pod name: delete-pod spec: checksum: sha256:a68bf570ea30e578e392eab18ca70dbece27bce850a8dbef2586eff55c5c7aa0 deps: | kubernetes\u0026gt;=12.0.1 function-content-type: text function: |- from kubernetes import client,config config.load_incluster_config() def delete_pod(event, context): rule = event[\u0026#39;data\u0026#39;][\u0026#39;rule\u0026#39;] or None output_fields = event[\u0026#39;data\u0026#39;][\u0026#39;output_fields\u0026#39;] or None if rule and rule == \u0026#34;Terminal shell in container\u0026#34; and output_fields: if output_fields[\u0026#39;k8s.ns.name\u0026#39;] and output_fields[\u0026#39;k8s.pod.name\u0026#39;]: pod = output_fields[\u0026#39;k8s.pod.name\u0026#39;] namespace = output_fields[\u0026#39;k8s.ns.name\u0026#39;] print (f\u0026#34;Deleting pod \\\u0026#34;{pod}\\\u0026#34; in namespace \\\u0026#34;{namespace}\\\u0026#34;\u0026#34;) client.CoreV1Api().delete_namespaced_pod(name=pod, namespace=namespace, body=client.V1DeleteOptions()) handler: delete-pod.delete_pod runtime: python3.7 deployment: spec: template: spec: serviceAccountName: falco-pod-delete EOF function.kubeless.io/delete-pod created kubectl get pods -n kubeless NAME READY STATUS RESTARTS AGE kubeless-controller-manager-99459cb67-tb99d 3/3 Running 3 3d14h delete-pod-d6f98f6dd-cw228 1/1 Running 0 2m52s kubectl get svc -n kubeless NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE delete-pod ClusterIP 10.43.211.201 \u0026lt;none\u0026gt; 8080/TCP 4m38s Test our function We start by creating a dumb pod:\nkubectl run alpine -n default --image=alpine --restart=\u0026#39;Never\u0026#39; -- sh -c \u0026#34;sleep 600\u0026#34; kubectl get pods -n default NAME READY STATUS RESTARTS AGE alpine 1/1 Running 0 9s Let's run a shell command inside and see what happens:\nkubectl exec -i --tty alpine -n default -- sh -c \u0026#34;uptime\u0026#34; 23:44:25 up 1 day, 19:11, load average: 0.87, 0.77, 0.77 As expected, we got the result of our command, but, to get the status of the pod now:\nkubectl get pods -n default NAME READY STATUS RESTARTS AGE alpine 1/1 Terminating 0 103s 💥 It has been terminated 💥\nWe can now check the logs of components.\nFor Falco:\nkubectl logs daemonset/falco -n falco {\u0026#34;output\u0026#34;:\u0026#34;23:39:44.834631763: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=alpine container=5892b41bcf46 shell=sh parent=\u0026lt;NA\u0026gt; cmdline=sh terminal=34817 container_id=5892b41bcf46 image=\u0026lt;NA\u0026gt;) k8s.ns=default k8s.pod=alpine container=5892b41bcf46\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Notice\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Terminal shell in container\u0026#34;,\u0026#34;time\u0026#34;:\u0026#34;2021-01-14T23:39:44.834631763Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;container.id\u0026#34;:\u0026#34;5892b41bcf46\u0026#34;,\u0026#34;container.image.repository\u0026#34;:null,\u0026#34;evt.time\u0026#34;:1610667584834631763,\u0026#34;k8s.ns.name\u0026#34;:\u0026#34;default\u0026#34;,\u0026#34;k8s.pod.name\u0026#34;:\u0026#34;alpine\u0026#34;,\u0026#34;proc.cmdline\u0026#34;:\u0026#34;sh\u0026#34;,\u0026#34;proc.name\u0026#34;:\u0026#34;sh\u0026#34;,\u0026#34;proc.pname\u0026#34;:null,\u0026#34;proc.tty\u0026#34;:34817,\u0026#34;user.loginuid\u0026#34;:-1,\u0026#34;user.name\u0026#34;:\u0026#34;root\u0026#34;}} For Falcosidekick:\nkubectl logs deployment/falcosidekick -n falco 2021/01/14 23:39:45 [INFO] : Kubeless - Post OK (200) 2021/01/14 23:39:45 [INFO] : Kubeless - Function Response : 2021/01/14 23:39:45 [INFO] : Kubeless - Call Function \u0026#34;delete-pod\u0026#34; OK (Notice, the function returns nothing, this is why the message log is empty)\nFor delete-pod function:\nkubectl logs deployment/delete-pod -n kubeless 10.42.0.31 - - [14/Jan/2021:23:39:45 +0000] \u0026#34;POST / HTTP/1.1\u0026#34; 200 0 \u0026#34;\u0026#34; \u0026#34;Falcosidekick\u0026#34; 0/965744 Deleting pod \u0026#34;alpine\u0026#34; in namespace \u0026#34;default\u0026#34; Conclusion With this simple example, we only scratched the surface of possibilities. Everything is possible now, so don't hesitate to share with us on Slack (https://kubernetes.slack.com #falco) your comments, ideas and successes. You're always welcome to contribute.\nBonus: You're running Falcosidekick outside Kubernetes but still want to use the Kubeless output? No problem, you can declare a kubeconfig file to use. See README.\nBonus 2: For people who wants to use Knative in place of Kubeless, it's coming soon 😉\nEnjoy\n","summary":"","tags":["Falcosidekick","Integration"],"title":"Kubernetes Response Engine, Part 1: Falcosidekick + Kubeless","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-response-engine-part-1-kubeless/"},{"category":"blog","content":"This fantastic post from @leodido about how has been the previous year 2020 for falco inspired me (link) I wanted to bring everyone up to speed on what we built for falcosidekick in 2020\nAside a lot of improvments and bug fixes, 8 new outputs have been integrated:\nRocketchat Mattermost Azure Event Hub Discord AWS SNS GCP PubSub Cloudwatch Logs Apache Kafka What really changed with previous releases was that almost all these outputs have been proposed and developed by other members of the falco community (kindly called the famiglia 😉). It warms my ♥️ a lot and makes me learn a lot about how to manage an open source project.\nThanks to everybody for your ideas, your comments, your help, your PR, your reviews, etc.\nThe following chart shows well how things are getting bigger and bigger for this small project that finally appeared useful for some people and companies.\nA special 🙏 to @cpanato, @KeisukeYamashita and @nibalizer, who are now official maintainers of falcosidekick with me. 🎉 to them!\nLast but not least, all my friendship to @danpopSD for his support and motivation. Merci mon ami.\nWhat's next? Release 2.20.0 Few times before this article is out we released one of the biggest versions since the beginning of falcosidekick. It results of a combination of a lot of efforts from many people.\nThe full changelog can be found here.\nThe main changes are three new outputs:\nSTAN (NATS Streaming) PagerDuty Kubeless (stay tuned, a post about this will be out soon 😉) And ? We believe the duo of falco + falcosidekick to be an obvious solution for most infrastructures, we are working hard to improve the code base and documentation. That will be all the major set of goals for the next major release 3.0.0 which is coming in the next few months. Until then with the help of n3wscott, we're working on adding the Cloudevents spec in a new HTTP output that will able to forward falco's events to more backends, like Knative.\nEnjoy\n","summary":"","tags":["Falcosidekick","Release"],"title":"Falcosidekick 2020","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosidekick-2020/"},{"category":"blog","content":"Let’s talk about Kubernetes security As Kubernetes continues to grow in adoption, it is important for us to know how to secure it. In a dynamic infrastructure platform such as Kubernetes, detecting and addressing threats is important but also challenging at the same time.\nFalco, the open source cloud native runtime security project, is one of the leading open source Kubernetes threat detection engines. Falco was created by Sysdig in 2016 and is the first runtime security project to join CNCF as an incubation-level project. Falco detects unexpected application behaviour and alerts on threats at runtime.\nWhy is it difficult? Security is one of the harder challenges of running Kubernetes according to this analysis. The reason it is difficult is that there are multiple moving layers in a cloud native stack, hence operators may not focus on security early on. Another contributor is that some distributions of Kubernetes may not be secure by default, contrary to what operators assume.\nPrevention and Detection Information security is a process that moves through phases building and strengthening itself along the way. Security is a journey, not a destination. Although the Information Security process has multiple strategies and activities, we can group them all into three distinct phases - prevention, detection, and response.\nPreventive measures Preventive measures include having proper access control, authentication and authorization in place. No matter what level of protection a system may have, it will get compromised given a greater level of motivation and skill. There is no foolproof “silver bullet” security solution. A defense in-depth strategy should be deployed so when each layer fails, it fails safely to a known state and sounds an alarm. The most important element of this strategy is timely detection and notification of a compromise.\nDetective measures An example of detective measures includes sending logs from security and network devices like host-based intrusion detection systems (HIDS) and network intrusion detection systems (NIDS) to an SIEM and building rules to alert when suspicious activity is seen. According to the defense in-depth approach, we should be auditing and placing detection triggers on multiple layers of the technology stack, from looking at cloud audit logs (like Cloudtrail), the Kubernetes cluster, containers, application code, host OS and the kernel. We will take a look at the detective measures in this blog which will further help us to respond to these threats.\nImage credit: @leodido\nSetting Falco up on Kubernetes The most secure way to run Falco is to install Falco directly on the host system so that Falco is isolated from Kubernetes in the case of compromise. Then the Falco alerts can be consumed via read-only agents running in Kubernetes. Falco can also be run directly in Kubernetes if isolation is not a concern. We will be setting Falco up using Helm in this tutorial, but you should be aware of the pros and cons of the method you are choosing.\nSteps Prerequisite: We need a working Kubernetes setup for this. You can use a cloud Kubernetes offering from AWS/GCP or set one up yourself locally using minikube. We also require kubectl and Helm to be installed on your client machine.\nLet’s start with the installation of Falco.\nAdd the falcosecurity repo in Helm\n$ helm repo add falcosecurity https://falcosecurity.github.io/charts $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the \u0026quot;falcosecurity\u0026quot; chart repository ...Successfully got an update from the \u0026quot;stable\u0026quot; chart repository Update Complete. ⎈Happy Helming!⎈ Installing the chart\n$ helm install falco falcosecurity/falco NAME: falco LAST DEPLOYED: Mon Nov 9 22:09:28 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Falco agents are spinning up on each node in your cluster. After a few seconds, they are going to start monitoring your containers looking for security issues. No further action should be required. After a few seconds Falco should be running, to verify, you will see the pods you created in a moment.\n$ helm ls $ kubectl get pods Setting up the environment We will need an environment to emulate the attacks and detect them. Let us set it up. We will be using Helm for this.\nLet's add Helm's stable repository and install mysql-db chart from it.\n$ helm repo add stable https://charts.helm.sh/stable $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the \u0026quot;falcosecurity\u0026quot; chart repository ...Successfully got an update from the \u0026quot;stable\u0026quot; chart repository Update Complete. ⎈Happy Helming!⎈ $ helm install mysql-db stable/mysql NAME: mysql-db LAST DEPLOYED: Mon Nov 9 22:11:07 2020 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: MySQL can be accessed via port 3306 on the following DNS name from within your cluster: mysql-db.default.svc.cluster.local\n… Let us now monitor Falco logs:\n$ kubectl get pods NAME READY STATUS RESTARTS AGE falco-6rr9r 1/1 Running 0 49m mysql-db-d5dc6b85d-77hrm 1/1 Running 0 47m ubuntu 1/1 Running 0 43m $ kubectl logs -f falco-6rr9r # Replace with your Falco pod name here Analyzing Falco’s logs The first steps when an attacker does after they gain access to a Kubernetes cluster is to enumerate available network hosts. An attacker will try to find their way around a seemingly new environment. They can try to use safe/less noisy commands to gain more insights from the cluster. Let us go through the steps an attacker might do and look at the corresponding detection signals from Falco. We will use the default ruleset which comes with Falco, these rules can be tuned as per your needs in your environment. You can find Falco’s default rules here: https://github.com/falcosecurity/falco/tree/master/rules\nTerminal shell in container Description: Detecting terminal shells being spawned in pods. We open a terminal shell on a running pod to replicate the scenario.\n$ kubectl exec -it mysql-db-d5dc6b85d-77hrm -- bash -il # Replace with the mysql pod name you have Detection:\n18:08:40.584075795: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=mysql-db-d5dc6b85d-77hrm container=3fc8155f9d1a shell=bash parent=runc cmdline=bash -il terminal=34816 container_id=3fc8155f9d1a image=mysql) k8s.ns=default k8s.pod=mysql-db-d5dc6b85d-77hrm container=3fc8155f9d1a Contact Kubernetes API Server From Container Description: We run kube-recon, which is a tool which does initial reconnaissance in a Kubernetes environment. This rule detects attempts to contact the Kubernetes API Server from a container.\n$ kubectl run kuberecon --tty -i --image octarinesec/kube-recon / # ./kube-recon 2020/11/09 18:21:22 Testing K8S API permissions 2020/11/09 18:21:23 Your K8S API Server is configured properly 2020/11/09 18:21:23 Running Nmap on the discovered IPs 2020/11/09 18:21:23 Getting local ip address and subnet 2020/11/09 18:21:23 Trying to download EICAR file 2020/11/09 18:21:23 Downloaded EICAR successfully. No malware protection is in place Detection:\n18:20:45.927730981: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=\u0026lt;NA\u0026gt; k8s.pod=\u0026lt;NA\u0026gt; container=4f63870599d0 shell=sh parent=\u0026lt;NA\u0026gt; cmdline=sh terminal=34816 container_id=4f63870599d0 image=octarinesec/kube-recon) k8s.ns=\u0026lt;NA\u0026gt; k8s.pod=\u0026lt;NA\u0026gt; container=4f63870599d0 18:21:22.657590195: Warning Docker or kubernetes client executed in container (user=root user_loginuid=-1 k8s.ns=default k8s.pod=kuberecon container=4f63870599d0 parent=kube-recon cmdline=kubectl get pods image=octarinesec/kube-recon:latest) k8s.ns=default k8s.pod=kuberecon container=4f63870599d0 18:21:22.723707794: Notice Unexpected connection to K8s API Server from container (command=kubectl get pods k8s.ns=default k8s.pod=kuberecon container=4f63870599d0 image=octarinesec/kube-recon:latest connection=172.17.0.5:56972-\u0026gt;10.96.0.1:443) k8s.ns=default k8s.pod=kuberecon container=4f63870599d0 Checking if shell is a container environment (Change thread namespace) Description: amicontained is a tool to check whether the shell is a containerized environment. The rule detects an attempt to change a program/thread's namespace.\n$ cd /tmp; curl -L -o amicontained https://github.com/genuinetools/amicontained/releases/download/v0.4.7/amicontained-linux-amd64; chmod 555 amicontained; ./amicontained Output: Container Runtime: docker Has Namespaces: pid: true user: false AppArmor Profile: kernel Capabilities: BOUNDING -\u0026gt; chown dac_override fowner fsetid kill setgid setuid setpcap net_bind_service net_raw sys_chroot mknod audit_write setfcap Seccomp: disabled Blocked Syscalls (19): MSGRCV SYSLOG SETSID VHANGUP PIVOT_ROOT ACCT SETTIMEOFDAY UMOUNT2 SWAPON SWAPOFF REBOOT SETHOSTNAME SETDOMAINNAME INIT_MODULE DELETE_MODULE LOOKUP_DCOOKIE KEXEC_LOAD OPEN_BY_HANDLE_AT FINIT_MODULE Detection:\n18:43:37.288344192: Notice Namespace change (setns) by unexpected program (user=root user_loginuid=-1 command=amicontained parent=bash k8s.ns=default k8s.pod=kuberecon container=c6112967b4f2 container_id=c6112967b4f2 image=octarinesec/kube-recon:latest) k8s.ns=default k8s.pod=kuberecon container=c6112967b4f2 Mon Nov 9 18:43:37 2020: Falco internal: syscall event drop. 9 system calls dropped in last second. 18:43:37.970973376: Critical Falco internal: syscall event drop. 9 system calls dropped in last second. (ebpf_enabled=0 n_drops=9 n_drops_buffer=0 n_drops_bug=0 n_drops_pf=9 n_evts=15232) Conclusion In this tutorial, we looked at the basics of Kubernetes security monitoring and how Falco allows us to use rules to achieve the detection of security issues. The default detection ruleset of Falco is enough to get yourself up and running, but you will most likely need to build on top of the default ruleset. If you have any feedback or suggestions feel free to reach out to me on Twitter @securetty_.\nThis post was first published on InfraCloud's blog on December 16, 2020.\n","summary":"","tags":null,"title":"An Introduction to Kubernetes Security using Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/intro-k8s-security-monitoring/"},{"category":"blog","content":"Falco on WSL2 You love Falco, just read the awesome blog Falco in 2020 - The Falco Project, and want to be part of this growing and wonderful community. \u0026quot;But\u0026quot; you are on Windows 10 and wonder how to run it?\nWell, the wait is over! Follow the Corsair on his WSL2 boat.\nPrerequisites In this blog post, the following technologies will be used:\nWindows 10 Insiders (Dev channel)\nThe version 21277 is the one used WSL2 feature enabled and default distribution installed\nIn this version, this has been done with the command:\nwsl --install --distribution ubuntu However, in this blog post, the [Ubuntu Community Preview](Announcing Ubuntu on Windows Community Preview - WSL2 - Ubuntu Community Hub) distro will be the one used\nLinux kernel version 5.10.4 (latest stable)\nThe default WSL2 kernel is now: 5.4.72-microsoft-standard-WSL2\nIf you still have a WSL2 kernel 4.x, then you can update it with the command\nwsl --update Attention: by compiling a new WSL2 kernel, the Microsoft custom module \u0026quot;DXGKRNL\u0026quot; will not be available\n[Optional]: Windows Terminal\nA (custom) Kernel for WSL2 First thing first, I won't be explain in details how to compile a kernel for WSL2. Simply because I already did that for the ZFS module.\nThis also means, I will have the pleasure to provide you with the juicy bits directly.\nNote: to ensure the best performances, all the work of compilation will be done from within the WSL2 filesystem.\nLet's launch the terminal with the WSL2 distro:\n# Move to your WSL2 home directory cd # Install the needed packages # Source: https://github.com/microsoft/WSL2-Linux-Kernel/blob/7015d6023d60b29c3be4c6a398bed923b48b4341/README-Microsoft.WSL2 sudo apt install -y build-essential flex bison libssl-dev libelf-dev # Get the latest stable Linux Kernel, but only the latest version of each file and only the specific branch we want # git needs to be installed git clone --depth 1 --branch linux-rolling-stable https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git # Ensure the \u0026#34;stable\u0026#34; branch is the active one cd linux git checkout linux-rolling-stable # Get a kernel config optimized for WSL2 # Source: https://github.com/microsoft/WSL2-Linux-Kernel/pull/176 wget https://raw.githubusercontent.com/microsoft/WSL2-Linux-Kernel/7015d6023d60b29c3be4c6a398bed923b48b4341/Microsoft/config-wsl -O .config # Change the LOCALVERSION value sed -i \u0026#39;s/microsoft-standard-WSL2/generic/\u0026#39; ./.config # [Optional] before we start the compilation, let\u0026#39;s \u0026#34;update\u0026#34; the config file to include the newest Kernel options make prepare ## The only option I didn\u0026#39;t choose the default value was: * * Preload BPF file system with kernel specific program and map iterators * Preload BPF file system with kernel specific program and map iterators (BPF_PRELOAD) [N/y/?] (NEW) y # Now that everything is ready, let\u0026#39;s compile the kernel make -j $(nproc) # Once the compilation is done, we can install the \u0026#34;optional\u0026#34; modules sudo make modules_install # Copy the kernel into a directory in the Windows filesystem # I recommend creating a wslkernel directory mkdir /mnt/c/wslkernel cp arch/x86/boot/bzImage /mnt/c/wslkernel/kernelfalco # Last step, the kernel needs to be referenced in the file .wslconfig # I\u0026#39;m using vi but feel free to use your preferred text editor vi /mnt/c/Users/\u0026lt;your username\u0026gt;/.wslconfig ## The content of the file should look like this ## Source: https://docs.microsoft.com/en-us/windows/wsl/wsl-config#wsl-2-settings [wsl2] kernel = c:\\\\wslkernel\\\\kernelfalco swap = 0 localhostForwarding = true With all these steps done, WSL2 can now be \u0026quot;rebooted\u0026quot; by running the following command in Powershell:\nwsl --shutdown Launch again a terminal with your WSL2 distro and confirm the new kernel is now being the one used:\nuname -a And here you have, the latest stable Linux kernel being installed/used by WSL2. The (big) upside of WSL2 is that all the distros are using the same kernel, without any further compilation needed. The (potential) downside is that all share the same configuration.\nLooking for SystemD on WSL2 By default, WSL2 does not run SystemD due to the customized init process. However, a very smart community member, Daniel Llewellyn, made it possible.\nSeveral iterations and alternatives are now available, however in this blog post, I'm using his \u0026quot;one script\u0026quot; as it does not require any additional package to be installed (=less intrusive).\nNote: while the kernel is applied to all WSL2 distros, the SystemD install will need to be done for every distro\nLet's jump again into the terminal:\n# Get the SystemD script and put it into /etc/profile.d sudo wget https://raw.githubusercontent.com/diddlesnaps/one-script-wsl2-systemd/master/src/00-wsl2-systemd.sh -O /etc/profile.d/00-wsl2-systemd.sh # [Optional] The script calls itself with sudo if the user is not root, so in order to avoid typing your password at every first WSL2 boot (after a shutdown only), you might want to add the following file to sudoers.d directory sudo wget https://raw.githubusercontent.com/diddlesnaps/one-script-wsl2-systemd/build-21286%2B/src/sudoers -O /etc/sudoers.d/wsl2-systemd And that's it, WSL2 can now be \u0026quot;rebooted\u0026quot; by running the following command in Powershell:\nwsl --shutdown Launch again a terminal with your WSL2 distro, this time you should see a small delay while systemd is starting.\nOnce the shell is ready, confirm SystemD is running:\nps -aux My name is Falco, Kernel module Falco With everything prepared, the next steps are to follow the Falco documentation, like someone with a \u0026quot;normal\u0026quot; Linux would do. Please remember I'm using Ubuntu and will follow the related section.\nHowever there will be a need for a \u0026quot;detour\u0026quot; related to the Kernel (and not WSL2). Instead of installing the headers from the repo (which did not exist at the time of writing this blog post), we will download them from the Ubuntu kernel website. For any other distro, please check on their respective site.\nNote: you can ignore the following errors when installing the Kernel headers packages\nW: mkconf: MD subsystem is not loaded, thus I cannot scan for arrays. W: mdadm: failed to auto-generate temporary mdadm.conf file.\nLet's jump again into the terminal:\n# Move to your WSL2 home directory cd # Run the step 1 of the Falco documentation: add the repo curl -s https://falco.org/repo/falcosecurity-packages.asc | sudo apt-key add - echo \u0026#34;deb https://download.falco.org/packages/deb stable main\u0026#34; | sudo tee -a /etc/apt/sources.list.d/falcosecurity.list sudo apt update # As stated above, for the step 2, let\u0026#39;s download the Kernel headers packages # In my case, I will take the \u0026#34;amd64\u0026#34; ones to match my CPU model. If you\u0026#39;re on ARM, download the matching ones wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10.4/amd64/linux-headers-5.10.4-051004_5.10.4-051004.202012301142_all.deb wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10.4/amd64/linux-headers-5.10.4-051004-generic_5.10.4-051004.202012301142_amd64.deb wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10.4/amd64/linux-image-unsigned-5.10.4-051004-generic_5.10.4-051004.202012301142_amd64.deb wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10.4/amd64/linux-modules-5.10.4-051004-generic_5.10.4-051004.202012301142_amd64.deb # Install the packages in this exact order, as the headers \u0026#34;generic\u0026#34; is depending on the headers \u0026#34;all\u0026#34; sudo dpkg -i linux-headers-5.10.4-051004_5.10.4-051004.202012301142_all.deb sudo dpkg -i linux-headers-5.10.4-051004-generic_5.10.4-051004.202012301142_amd64.deb sudo dpkg -i linux-image-unsigned-5.10.4-051004-generic_5.10.4-051004.202012301142_amd64.deb sudo dpkg -i linux-modules-5.10.4-051004-generic_5.10.4-051004.202012301142_amd64.deb # Install Falco from the repository sudo apt install -y falco With Falco now installed, there's still some steps needed to \u0026quot;enable and test it\u0026quot;. Once again, the Falco documentation is ready and I will follow it here.\nOne last time (for this blog at least), let's jump into the terminal:\n# Check the kernel loaded modules # Falco should not appear lsmod # Enable the Falco service and start it sudo systemctl enable falco sudo systemctl start falco # Check again the kernel loaded modules # Falco should appear now lsmod # View the Falco logs journalctl -fu falco CONGRATULATIONS!!! You have now Falco up and running in WSL2 and ready to be used with your preferred Kubernetes distro (cf. the Falco documentation).\nConclusion I hope this blog helped you getting Falco into WSL2 and you can now not only test it, but also provide feedback to this wonderful team.\nIf you have any questions or feedback on Falco, do not hesitate to create an issue on Falco GitHub repo and for WSL2 more specifically, you can reach me on Twitter (@nunixtech)\nSee you in the Cloud Native seas.\nThe WSL Corsair\n","summary":"","tags":null,"title":"Falco on WSL2 with a custom kernel","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-wsl2-custom-kernel/"},{"category":"blog","content":"The scope of this post is to review the progress of Falco and its community during the pandemic year. A year will never forget.\nI will try to keep it compact, but Falco, and its community, grown so much this year that I feel like this could be a blog posts series.\n2020 was the year we completely and finally put the Falco release process in the open! 📖\nWhen Lorenzo and I joined Sysdig in 2019 it was not.\nThis was a mandatory requirement that came out from the process to move Falco into the CNCF incubation level.\nSo yes, 2020 is also the year Falco got accepted as an incubation-level hosted project by the Cloud Native Computing Foundation!\nThe Falco release process is now open, some Falco maintainers propose themselves during our Community Calls, and they lead the next Falco release, which happens every 2 months. 🔄\nWhile moving the release process in the open, we also took the chance to:\ngive Falco a clearer and coherent SemVer 2.0 versioning scheme separate the Falco drivers version from the Falco version rename the drivers in a more coherent way reorganize its artifacts every merge on the master branch and every new release create Falco packages automatically now and push them to package repositories (tarball, DEB, and RPM) on download.falco.org 📦 reorganize its container images every merge on the master branch and every new release, automatically build and publish container images on the DockerHub 🐳 soon on the AWS ECR Gallery, too (1512 soon to be merged in!) set-up a process to evolve and incubate new Falco projects and community resources in the falcosecurity GitHub organization ↗ In case you wanna know more on these topics this and this are the Falco blog posts you need to read.\nIn the meantime, we built driverkit 🗜 to let our users manually prebuild the Falco drivers for their hosts. And we created a Drivers Build Grid using this tool, making it able to run initially on CircleCI, now on our Falco Infra backed by Prow and Kubernetes on AWS.\nWe finally re-organized the way we store the prebuilt Falco drivers. Take a look at download.falco.org.\nWould you rather take a look at the Falco Infra that I mentioned? 🛠\nTake a look at prow.falco.org. What an awesome outcome!\nIn case this topic really got you, well you can read all the details in 🔗 this blog post I co-authored with Jonah on the AWS Open Source blog.\nI want to publicly thank all the Falco Infra WG participants (Spencer, Massimiliano, Lorenzo, Grasso, Umang), especially Jonah from Amazon for all the help he gave and continues to give us as a new maintainer!\nAnother area that had a huge role in the Falco adoption is the Falco Helm chart. 📋\nWe internalized, fixed, and constantly improved them. Our community loves them so much that external contributors - like Spencer - help us keep the charts healthy daily.\nTo not mention falcosidekick. 🔫\nWhat Thomas did here to enhance Falco output alerts is just awesome. Listing here all the tools he integrated with the Falco outputs alerts would make this post even longer.\nSo, please go read this blog post (part #4 🔗) by POP to know more about them.\nSince I just mentioned him, and in case you still don't know: POP, my big ItaloAmericano friend, joined us with the intent to help the Falco community and ecosystem shine to unprecedented levels. Make no mistake: he's a great addition to the Falco community.\nI presume it's clear now that 2020 was the year the Falco community took off definitely! Innit?\nLook how many maintainers we have now by taking a look at this beautiful maintainers.yaml I instructed our Falco Infra to generate. 👥\nWe took on board a lot of new external contributors from different companies (IBM, Amazon, Mercari, Hetzner Cloud, DeltaTre, etc.) and they made the difference.\nThis is the Open Source power, this is what happens when people come together. 🤗\nFrom a technical point of view, the toughest and most important (IMHO) contribution to Falco was the fix of the Falco eBPF driver back in March developed by Lorenzo and me. 🔬\nIn fact, as I said, the real issue was in the eBPF VM: it would have impacted many other eBPF programs potentially leading to tedious and dangerous situations.\nAnyway, a lot has been done over the past year to improve the Falco core tech too.\nThe top things (in no particular order) that I can recall right now are (forgive me in case I forget something):\nFixing the presence of \u0026lt;NA\u0026gt; values in the Falco alerts (1133, 1138, 1140, 1492) 🩺 Playing with valgrind to fix various memory leaks 🔩 Improving the performances of the gRPC Falco Outputs API and making it bi-directional (1241) 👉👈 The port of the Falco outputs mechanism from Lua to C++ (thanks Grasso for 1412) 🔧 Adding other gRPC APIs to the Falco core Version API Stream the drop alerts too with the gRPC Falco Outputs API Investigating the drops 100% statically-linked version of Falco (thanks Lorenzo!) ⛓ Build Falco on aarch64 (many thanks to Lorenzo again: 1442) ⚙ Userspace instrumentation, making Falco able to run without the kernel module or the eBPF probe And the first userspace Falco driver - ie., pdig - thanks to Loris and Grzegorz I'm 100% sure I forgot something important. But, given the quantity of Panettone I have eaten today 🍞, I consider what I remembered and written here a damn good result for my brain.\nA glimpse of 2021 Stay tuned, because 2021 is the year we plan to make Falco programmable by our users. 📻\nWe're writing a real Falco rules language - ie., with a compiler and everything. ⚗\nWe're prepping a set of cool C APIs (libhawk maybe?) to let you interact with Falco (starting with its rulesets) while it runs. 🧪\nWe're revamping the Falco website (watch falco-website#324).\nGet ready to also read a cool new developer's documentation (watch 1513) website and contribute to the Falco core! 📔\n","summary":"","tags":null,"title":"Falco in 2020","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-2020/"},{"category":"blog","content":"A familiar scenario Imagine installing a security tool that requires privileged access using the Kubernetes API. Now imagine our cluster is compromised. As an attacker, the first thing I would do would be to ensure that whatever security tool you were running in Kubernetes - was turned off. Fortunately if I compromised your cluster there is a very lush toolchain that would make that very easy for me.\nWhy I run Falco directly on Linux Fundamentally I disagree with running a security tool in the same layer of the stack that it hopes to protect. That is effectively like keeping the keys to your front door conveniently hung on the outside of a locked door. The goal is for multiple layers of the stack to watch each other such that if one is compromised you still have control of another. Putting everything in Kubernetes violates this.\nI understand that Falco is easy to use, and installing it with Helm is fun.\nI run 5 public facing Dell poweredge servers on a /29 with BGP and I assure you I have offended more people on the internet than you can imagine. I do not have Falco running in Kubernetes. I run Falco with systemd. Yes I have found hackers with it. Yes they have gained access to unwanted parts of my cluster.\nThe Helm chart is a great place to get started!\nHow I do it Here is how I install and run Falco in production.\nCheck out the latest tag (Great job team!)\nNote: If you are running Arch you need an updated Kernel and packages Running this on a 4.19 kernel.\ngit fetch git checkout tags/0.26.2 -b branch-0.26.2 cmake ../ \\ -DBUILD_BPF=\u0026#34;ON\u0026#34; \\ -DBUILD_WARNINGS_AS_ERRORS=\u0026#34;OFF\u0026#34; \\ -DCMAKE_BUILD_TYPE=\u0026#34;Release\u0026#34; \\ -DCMAKE_INSTALL_PREFIX=\u0026#34;/usr\u0026#34; \\ -DFALCO_ETC_DIR=\u0026#34;/etc/falco\u0026#34; \\ -DUSE_BUNDLED_DEPS=ON make bpf make falco make install Here is my unit file in /lib/systemd/system\n[Unit] Description=Falco Runtime Security [Service] ExecStart=/usr/bin/falco --pidfile=/var/run/falco.pid -c /etc/falco/falco.yaml ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=always\n[Install] WantedBy=multi-user.target I enable the service\nsystemctl enable falco systemctl start falco Conclusion Yes -- I run Falco on Linux with eBPF - and it works great. If my cluster ever gets attacked I know that I have good Linux security in place to prevent any more escalation. I understand out what happened. I fix the problem.\nIn conclusion, we see this question a lot. Having a boundary between your cluster and your host is wise. Installing Falco using Kubernetes breaks that boundary. This is how I do things.\n","summary":"","tags":null,"title":"Security boundaries with Kubernetes and systemd","url":"https://v0-43--falcosecurity.netlify.app/blog/security-boundaries-with-systemd-and-kubernetes/"},{"category":"blog","content":"Today we announce the release of Falco 0.26.2 🥳\nThis one is a hotfix release for the Falco 0.26.1 released on October 1st.\nYou can take a look at the set of changes here:\n0.26.2 As usual, in case you just want to try out the stable Falco 0.26.2, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Do you rather prefer using the docker images? No problem!\nYou can read more about running Falco with Docker in the docs.\nWhy this release? When you install Falco, you will either use a Kernel module, an eBPF probe or userspace instrumentation driver as described in the documentation.\nAs a service to our community, the Falco Infrastructure WG publishes pre-built drivers for all the current driver versions using the driverkit build grid.\nDue to a spike in adoption in the month of October 2020, we had to come up with a better strategy for distributing our pre-built drivers.\nTo achieve this, we decided that from now on we will publish the drivers only to download.falco.org/driver instead of dl.bintray.com/falcosecurity/driver. Old drivers will be kept there to avoid disruption of current workloads but we will not publish new versions to the old bucket anymore. The PR that made this happen can be found here.\nWe also had a proposal that was discussed \u0026amp; approved for this change to happen, you can find it here\nWhat should I do? If you install Falco using a docker image and rely on our prebuilt drivers you have two options:\nRECOMMENDED: Update to 0.26.2\nAlternatively, you can change the DRIVERS_REPO environment variable in your current environment.\nOn bash:\nexport DRIVERS_REPO=https://download.falco.org/driver falco-driver-loader Docker\nPass it as environment variable using the docker run flag -e - for example:\ndocker run -e DRIVERS_REPO=https://download.falco.org/driver Kubernetes\nspec: containers: - env: - name: DRIVERS_REPO value: https://download.falco.org/driver What's next? We have a scheduled 0.27.0 release on December 1st!\nIt will contain a lot of exciting features and performance improvements! Stay tuned 🤙\nLet'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!\nIf you have any questions\nJoin the #falco channel on the Kubernetes Slack Join the Falco mailing list Bye!\nLeo \u0026amp; Lore\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.26.2 a.k.a. \"the download.falco.org release\"","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-26-2/"},{"category":"blog","content":"Today we announce the release of Falco 0.26.1 🥳\nThis one is a hotfix release for the Falco 0.26.0 released last week!\nYou can take a look at the set of changes here:\n0.26.1 0.26.0 As usual, in case you just want to try out the stable Falco 0.26.1, you can install its packages following the process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu openSUSE Do you rather prefer using the docker images? No problem!\nYou can read more about running Falco with Docker in the docs.\nWhat's new? From this Falco version onwards, if you download Falco using the tarball distribution (binary) or the falcosecurity/falco-no-driver container image, you will get a 100% statically-linked version of Falco! ⛓\nThe use case for this is that you can now download the tarball and copy the Falco binary (and configuration files) to any target machine or container without depending on the underlying system libraries, included libc.\nThe userspace working group is already using this in the experiments to bring Falco to new endeavors like AWS Fargate. 🕶\nRules As always, our rules set is constantly improving and adapting to the constantly changing world. Many thanks to @ldegio, @mstemm, @csschwe and @leogr.\nWhat's next? As always, you have a chance to be part of this release by joining our community calls!\nIn the last Falco call the community chose to release Falco every 2 months, from now on. ⏰\nSo, we just created the milestone for 0.27.0 due by December 1st, 2020.\nSee you in winter!\nLeo \u0026amp; Lore\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.26.1 a.k.a. \"the static release\"","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-26-1/"},{"category":"blog","content":"Falco works by taking Linux system call information at runtime, and rebuilding the state of the kernel in memory. The Falco engine depends on a driver in order to consume the raw stream of system call information. Currently the Falco project supports 3 different drivers in which the engine can consume this information.\nA kernel module An eBPF probe A ptrace(2) userspace program This blog will highlight the nuances of each implementation and explain why they exist. Hopefully this resource will give you a starting point for understanding which driver is right for your use case.\nUpdated: Falco 0.26.0\nKernel Module The Falco Kernel module is the traditional way of consuming the required stream of data from the kernel.\nSource: github.com/falcosecurity/libs/driver\nThe kernel module must be loaded in order for Falco to start. The kernel module depends on the linux-headers package in order to compile. More information .\nNote: A convenience script found here\nUsing the kernel module cd ~ git clone https://github.com/falcosecurity/falco cd falco mkdir build cd build cmake ../ \\ -DBUILD_BPF=OFF \\ -DBUILD_WARNINGS_AS_ERRORS=\u0026#34;OFF\u0026#34; \\ -DCMAKE_BUILD_TYPE=\u0026#34;Release\u0026#34; \\ -DCMAKE_INSTALL_PREFIX=\u0026#34;/usr\u0026#34; \\ -DFALCO_ETC_DIR=\u0026#34;/etc/falco\u0026#34; \\ -DUSE_BUNDLED_DEPS=ON make driver sudo insmod driver/falco.ko sudo falco Pros The kernel module is the most commonly used driver for Falco and can be used in any environment where loading a kernel module is trusted and viable.\nThe module can be built, hosted, and installed directly onto a hosted system. The Falco community offers limited support for pre-building kernel modules. Will work regardless of kernel version (as compared to eBPF below) Cons Tightly coupled with the host kernel and changing kernel versions, architecture, operating systems can introduce complexity. A faulty kernel module could potentially panic or crash a Linux kernel. Loading a kernel module is not always trusted or allowed in some environments. Summary Kernel modules are the quickest, and most common way to run Falco. They are a viable solution in any environment where access to the host kernel is trusted.\nKubernetes AWS EC2 (kops, eks, kubeadm) Anywhere access to the host is allowed Azure IBM Cloud eBPF Probe The Falco eBPF probe is a viable option in environments where kernel modules are not trusted or are not allowed but eBPF programs are. The most common example of this environment is GKE. Running Falco in GKE was the original use case for creating the eBPF probe.\nSource: github.com/falcosecurity/libs/driver/bpf\nThe eBPF probe must be loaded in order for Falco to start, and will provide the same stream of metrics that the kernel module does. Falco should work seamlessly with this approach.\nUsing the eBPF probe Note: Notice the -DBUILD_BPF=ON flag Note: A convenience script found here\ncd ~ git clone https://github.com/falcosecurity/falco cd falco mkdir build cd build cmake ../ \\ -DBUILD_BPF=ON \\ -DBUILD_WARNINGS_AS_ERRORS=\u0026#34;OFF\u0026#34; \\ -DCMAKE_BUILD_TYPE=\u0026#34;Release\u0026#34; \\ -DCMAKE_INSTALL_PREFIX=\u0026#34;/usr\u0026#34; \\ -DFALCO_ETC_DIR=\u0026#34;/etc/falco\u0026#34; \\ -DUSE_BUNDLED_DEPS=ON make bpf cp driver/bpf/falco.o ${HOME}/.falco/probe.o sudo falco Pros The eBPF probe can be ran in environments like GKE where loading a kernel module is not an option. eBPF is considered safer, and unable to crash or panic a kernel. The eBPF code is already compiled into a Linux kernel, and is simply enabled using the eBPF program. The eBPF probe can be dynamically loaded into a kernel at runtime, and does not require using tools like dkms, modprobe, or insmod to load the program. Cons The eBPF probe does not work for every system. You need at least Linux kernel version 4.14 but the Falco project suggests an LTS kernel of 4.14/4.19 or above. Summary The eBPF probe should be used when loading a kernel module is not a viable option. Reasons for not loading a kernel module may change, and in this case the eBPF probe is the default.\nKubernetes GKE Environments where loading a kernel module is untrusted or not supported pdig The pdig binary is the newest and most viable path forward when both a kernel module, and eBPF probe is not an option. The most common example of this environment is AWS ECS with Fargate.\nThe pdig tool is built on ptrace(2). It requires CAP_SYS_PTRACE enabled for the container runtime. The pdig tool enables a new way of consuming metrics about a given application at the process level.\nNote: The eBPF probe and kernel module work at a global host level, whereas pdig works at a process level. A clever invocation of pdig against a system can simulate a broader scope of system parsing. PID 1 is sometimes of interest.\nSource: github.com/falcosecurity/pdig\nPros Lightweight, safe, and process specific Runs only in userspace Enables Falco for use cases when a kernel module, and an eBPF probe is not viable Cons The dependency on ptrace(2) is slow. Period. Requires executing Falco with the pdig binary to \u0026quot;hack\u0026quot; the driver. Summary The pdig tool is the most unique of all the drivers, and enables functionality not otherwise possible.\nKubernetes AWS ECS/Fargate AWS EKS/Fargate Environments where kernel modules and eBPF is not an option Suggested Cloud Provider Implementations Solution Suggested Driver More Resources Baremetal Kubernetes Kernel Module Helm Chart Kubeadm Kubernetes Kernel Module Helm Chart Kubernetes Kind Kernel Module Kind Documentation Minikube Kernel Module Minikube Documentation AWS EKS Kernel Module Helm Chart Azure Kernel Module Helm Chart GKE eBPF Probe Falco on GKE IBM Cloud Kernel Module Helm Chart OpenShift Kernel Module Helm Chart AWS ECS pdig pdig falco-trace AWS EKS (Fargate) pdig pdig falco-inject ARM/Raspberry PI eBPF Probe *Kernel specific ","summary":"","tags":null,"title":"Choosing a Falco driver","url":"https://v0-43--falcosecurity.netlify.app/blog/choosing-a-driver/"},{"category":"blog","content":"Today we announce the release of Falco 0.25 🥳\nThis one is a small release but a very important one!!\nYou can take a look at the set of changes here:\n0.25.0 In case you just want to try out the stable Falco 0.25, you can install its packages following the usual process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu Do you rather prefer using the docker images? No problem!\nYou can read more about running Falco with Docker in the docs.\nWhat's new? Driver changes The driver now supports the renameat2 syscall and works with new kernel stable 5.8 releases!\nInstallation experience Before, users had to install libyaml in their systems, it's not needed anymore.\nContributor experience We have improved the contribution experience by rewriting the step by step instructions to run integration tests locally, the instructions can be found here.\nMoreover, the build experience was improved as many users were reporting build problems on different operating systems, we took a chance to restructure our builds a bit and make them easier to work with.\nThanks to @leodido!\nOutputs plugin developer experience Outputs plugin developers and maintainers must be aware that gRPC was updated to 1.31.1. Please take your time to test and report issues, thank you!\nRules As always, our rules set is constantly improving and adapting to the constantly changing world. Many thanks to @Kaizhe, @nvanheuverzwijn, @admiral0 and @leogr.\nWhat's next? We just created the milestone for 0.26.0 due by September 15, 2020. As always, you have a chance to be part of this release by joining our community calls!\nSee you soon!\nLore and Leo Grasso\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.25.0 a.k.a. \"the summer release\"","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-25-0/"},{"category":"blog","content":"After two long months, look who's back!\nToday we announce the release of Falco 0.24 🥳\nYou can take a look at the huge set of changes here:\n0.24.0 In case you just want to try out the stable Falco 0.24, you can install its packages following the usual process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu Do you rather prefer using the docker images? No problem!\nYou can read more about running Falco with Docker in the docs.\nBreaking Changes In case you wanna grab statistics about your running Falco instance, be aware that this PR fixed and changed the name of the CLI flag you need to enable such feature. The flag is --stats-interval now and finally, it also works for values greater than 999 milliseconds.\nBecause of performance issues of the Falco gRPC Outputs API we went through an almost complete redesign of the gRPC server and the outputs RPCs.\nLong story short: the gRPC outputs method is now falco.outputs.service/get and not falco.outputs.service/subscribe anymore.\nFurthermore, we introduced a falco.outputs.service/sub gRPC method that behaves in the same way the old one was behaving, except that it is way faster than the old method.\nNotorious gRPC fixes and features Some months ago, a user reported a very high CPU usage when using Falco gRPC outputs API with Falco 0.21.\nProfiling the code we discovered that the gRPC threads were keeping the CPUs very very busy.\nDigging deeply into the gRPC code and the gRPC core, Leo and Lore soon realized that to solve the issue a rewrite of important pieces of the Falco gRPC code was needed.\nSo we introduced a bidirectional API (falco.outputs.service/sub) to watch the Falco alerts through gRPC and we changed the server streaming gRPC outputs method (falco.outputs.service/get) to consume less memory and fewer CPU resources.\nAfter some days of fine-tuning and continuous tests (4MLN requests towards the gRPC server, in 10 seconds) we've been able to reduce the CPUs occupancy of the gRPC outputs methods from nearly ~90% to values less than 20%. 🚀\nIn that PR you can find all the story, all the code changes, and also the instructions to quickly try out the new Falco gRPC output methods using grpcurl.\nSo, all's well that ends well: users are now happy and we too! 🤗\nFinally, now that Falco gRPC outputs are better, we want to advertise the community about two other important and gRPC related features that Falco 0.24 ships:\nyou can now let Falco automatically configure the threadiness of its gRPC server by using threadiness: 0 into the Falco config (falco#1271) lo and behold, you can now connect to the Falco gRPC server through a Unix socket (falco#1217) We already updated the Falco Go client.\nSo, we'd invite all the Falco community and users to try out these new features and the improvements about gRPC!\nSupport for eBPF driver on CentOS 8 is back! Since April some friends of our community reported issues on building the Falco eBPF driver on CentOS 8 (falco#1129).\nAfter some intensive debugging sessions, Lorenzo and Leo discovered the cause: CentOS 8 backported process type functionalities (and relates structs) from Linux kernel 4.19 to 4.18 that made the driver checks ineffective.\nDo you wanna look at some eBPF? Take a look at this PR!\nFalco driver version 85c8895 contains the fix so that y'all can again run our beloved tool on your CentOS 8 boxes. 📦\nUnbuffered outputs 😆 Leonardo Grasso finally spotted a tricky typo that was causing buffered_output: false config option to do not work as expected.\nThanks to his fix, from now on Falco will promptly output its alerts on stdout when this option is disabled.\nAlso, we'd like to welcome Grasso in the family of Falco maintainers!\nRules update We are very thankful to Khaize for this huge PR that introduces a bunch of placeholder macros.\nThanks to his effort, users can now customize their own Falco rulesets more easily!\nSome statistics 38 pull requests merged in, 29 of which containing changes directly targeting our end-users.\n105 commits since past release, that was two months ago.\nBe aware: userspace instrumentation is coming... In this release Falco introduces userspace level instrumentation contract.\nThis functionality can be enabled by passing the -u flag when starting Falco, or using its long version - ie., --userspace.\nA userspace implementation will also need to be implemented as well to take advantage of this contract.\nThe Falco community is currently working on an implementation called pdig which is built around ptrace(2) and seccomp. We are very excited to see pdig reach production support in the future.\nRead more into the Falco website.\nSee you in August with many more things!\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.24.0 a.k.a. \"the huge release\"","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-24-0/"},{"category":"blog","content":"CVE-2020-8557 The /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager when calculating ephemeral storage usage by a pod. If a pod writes a large amount of data to the /etc/hosts file, it could fill the storage space of the node and cause the node to fail which acts as DoS attack.\nSeverity Medium Affected Kubernetes Versions kubelet v1.18.0-1.18.5 kubelet v1.17.0-1.17.8 kubelet \u0026lt; v1.16.13 Detecting CVE-2020-8557 with Falco Detecting exploitation attempts of this vulnerability is critical. Falco is the CNCF open source project for runtime threat detection for containers and Kuberenetes. You can use Falco to detect malicious activity both at the host and at the container level. Falco will generate security events when it finds abnormal behaviours, which are defined by a customizable set of rules.\nOne of the benefits of Falco is in leveraging its powerful and flexible rules language. Meanwhile, Falco comes with a handful out-of-box detection rules. Let’s see how we can detect when someone is trying to exploit CVE 2020-8557.\nThe vulnerability is due to the fact that the /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager. Usually when incompressible compute resource consumption like memory and disk hits the eviction threshold, the kubelet eviction manager will start evicting pods in order to preserve the availability of both the worker node and other pods running on the node. Meanwhile, /etc/hosts is also an important file to the system, As your machine gets started, it will need to know the mapping of some hostnames to IP addresses before DNS can be referenced. This mapping is kept in the /etc/hosts file. In the absence of a name server, any network program on your system consults this file to determine the IP address that corresponds to a host name. In the Falco out-of-box rules, there is one particular rule to detect any modification under /etc folder which includes /etc/hosts file.\n- rule: Write below etc desc: an attempt to write to any file below /etc condition: write_etc_common output: \u0026#34;File below /etc opened for writing (user=%user.name command=%proc.cmdline parent=%proc.pname pcmdline=%proc.pcmdline file=%fd.name program=%proc.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] container_id=%container.id image=%container.image.repository)\u0026#34; priority: ERROR tags: [filesystem, mitre_persistence] Or you can have this particular rule for the CVE:\n- rule: Detect Write Below /etc/hosts desc: an attempt to write to /etc/hosts file (CVE-2020-8557) condition: open_write and container and fd.name=/etc/hosts output: \u0026#34;File /etc/hosts opened for writing (user=%user.name command=%proc.cmdline parent=%proc.pname pcmdline=%proc.pcmdline file=%fd.name program=%proc.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] container_id=%container.id image=%container.image.repository)\u0026#34; priority: ERROR tags: [filesystem, mitre_persistence] When there is file write activity happen on the /etc/host file, the Falco rule above will be triggered and he output would be like following:\nFile /etc/hosts opened for writing (user=root command=bash parent=bash pcmdline=bash file=/etc/hosts program=bash gparent=\u0026lt;NA\u0026gt; ggparent=\u0026lt;NA\u0026gt; gggparent=\u0026lt;NA\u0026gt; container_id=384fc3447d54 image=kaizheh/nginx) And when check the file size on the worker node, you will find the followings:\nroot@ip-172-20-48-137:/home/admin# find /var/lib/kubelet/pods/*/etc-hosts -size +1M /var/lib/kubelet/pods/a8e75db1-b0cf-487a-ab5c-8041d33824f1/etc-hosts The size of /etc/hosts file on the worker node is greater than 1M.\nMitigation Strategy As the vulnerability is targeted at /etc/hosts file. A specific mitigation strategy is to apply the following AppArmor profile to your running containers:\n#include \u0026lt;tunables/global\u0026gt; profile cve-2020-8557 flags=(attach_disconnected,mediate_deleted) { #include \u0026lt;abstractions/base\u0026gt;\naccessing to network resources are subject to change per container network inet tcp, network inet udp, network inet icmp, deny network raw, deny network packet,\nfile, Umount,\ndeny writes to /etc/hosts file deny /etc/hosts wl,\ncapabilities are subject to changes per container capability chown, capability dac_override, capability setuid, capability setgid, } The preceding AppArmor profile allows most of the activities from a container but deny writing to /etc/hosts file.\nConclusion Prior to upgrading, it’s important to apply the mitigation strategy. In addition to preventing the vulnerability from being exploited, it is also important to detect or monitor any file write on the /etc/hosts file. Check out Falco and Sysdig Secure for more information to help mitigate the vulnerability.\nReferences https://github.com/kubernetes/kubernetes/issues/93032 https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/\n","summary":"","tags":null,"title":"Detect CVE-2020-8557 using Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/detect-cve-2020-8557/"},{"category":"blog","content":"(2021-04-13) edit: update to integrate Falcosidekick-UI use last versions of Falco helm chart which embeds Falcosidekick as dependency\nBy default, Falco has 5 outputs for its events: stdout, file, gRPC, shell and http. As you can see in the following diagram:\nEven if they're convenient, we can quickly be limited to integrating Falco with other components. Here comes Falcosidekick, a little daemon that extends that number of possible outputs.\nThe current list of available Falcosidekick outputs (version v2.22.0) is:\nSlack Rocketchat Mattermost Teams Datadog Discord AlertManager Elasticsearch Loki NATS STAN (NATS Streaming) Influxdb AWS Lambda AWS SQS AWS SNS AWS CloudWatchLogs AWS S3 SMTP (email) Opsgenie StatsD (for monitoring of falcosidekick) DogStatsD (for monitoring of falcosidekick) Webhook Azure Event Hubs Prometheus (for both events and monitoring of falcosidekick) GCP PubSub GCP Storage Google Chat Apache Kafka PagerDuty Kubeless OpenFaaS WebUI (a Web UI for displaying latest events in real time) Beyond that, it provides metrics about the number of events and let you add custom fields in events, for example environment, region, etc\nIn this article, we'll see how to deploy together in a Kubernetes cluster Falco, Falcosidekick and Falcosidekick-UI.\nWe'll use Helm (version 3) for installing all components and for a better user experience, the official Falco chart is able to install and set all configurations for us:\nFor this tutorial, we'll send the events in a Slack channel, so get your webhook URL first.\nRun the following Helm\nkubectl create namespace falco helm repo add falcosecurity https://falcosecurity.github.io/charts helm install falco falcosecurity/falco \\ --set falcosidekick.enabled=true \\ --set falcosidekick.webui.enabled=true \\ --set falcosidekick.config.slack.webhookurl=\u0026#34;https://hooks.slack.com/services/XXXX\u0026#34; \\ -n falco --set falcosidekick.enabled=true enables deployment of Falcosidekick aside Falco and configures Falco for sending its events to Falcosidekick --set falcosidekick.webui.enabled=true enables deployment of Falcosidekick-UI and configure Falcosidekick for using it as output --set falcosidekick.config.slack.webhookurl=\u0026quot;https://hooks.slack.com/services/XXXX\u0026quot; enables Slack as output for Falcosidekick All possible values can be seen in the according Helm charts, see the repository\nAfter few seconds you should get:\nkubectl -n falco get pods NAME READY STATUS RESTARTS AGE falco-falcosidekick-ui-7bdc54fb4c-h99b6 1/1 Running 0 26s falco-falcosidekick-7779579477-pfspz 1/1 Running 0 26s falco-falcosidekick-7779579477-bn8pv 1/1 Running 0 26s falco-6ksbx 1/1 Running 0 26s falco-pxvbk 1/1 Running 0 26s falco-5cg5b 1/1 Running 0 26s kubectl -n falco get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE falco-falcosidekick ClusterIP 10.43.212.119 \u0026lt;none\u0026gt; 2801/TCP 61s falco-falcosidekick-ui ClusterIP 10.43.35.87 \u0026lt;none\u0026gt; 2802/TCP 60s You can test the deployment of Falcosidekick with a typical port forward:\nkubectl -n falco port-forward svc/falco-falcosidekick 2801 curl -s http://localhost:2801/ping pong It's alive !\nWe can send a test event to Slack to test whether it works or not. Falcosidekick provides a useful endpoint for that:\ncurl -sI -XPOST http://localhost:2801/test HTTP/1.1 200 OK Date: Tue, 13 Apr 2021 20:42:32 GMT Content-Length: 0 In logs you'll get:\nkubectl -n falco logs deployment/falcosidekick kubectl logs deployment/falco-falcosidekick -n falco Found 2 pods, using pod/falco-falcosidekick-7779579477-pfspz 2021/04/13 20:40:11 [INFO] : Enabled Outputs : [Slack WebUI] 2021/04/13 20:40:11 [INFO] : Falco Sidekick is up and listening on :2801 2021/04/13 20:41:35 [INFO] : WebUI - Post OK (200) 2021/04/13 20:41:35 [INFO] : WebUI - Publish OK 2021/04/13 20:41:35 [INFO] : Slack - Post OK (200) 2021/04/13 20:41:35 [INFO] : Slack - Publish OK We can notice the fist line of logs [INFO] : Enabled Outputs : [Slack WebUI], we do have 2 enabled outputs, Slack and WebUI (Falcosidekick-UI)\nAnd in your Slack channel:\nTip: For Slack and some other ouputs, the message format can be customized, more informations in README\nWe'll now add some custom fields and test a more realistic event.\nUpgrade your deployment:\nhelm upgrade falco falcosecurity/falco \\ --set falcosidekick.enabled=true \\ --set falcosidekick.webui.enabled=true \\ --set falcosidekick.config.slack.webhookurl=\u0026#34;https://hooks.slack.com/services/XXXX\u0026#34; \\ --set falcosidekick.config.customfields=\u0026#34;environment:production\\,datacenter:paris\u0026#34; -n falco Send a more advanced test event to Falcosidekick (still with the port forward aside):\ncurl \u0026#34;http://localhost:2801/\u0026#34; -d\u0026#39;{\u0026#34;output\u0026#34;:\u0026#34;A more realistic test event\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Error\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Fake rule\u0026#34;,\u0026#34;time\u0026#34;:\u0026#34;2021-04-13T20:58:00.746609046Z+2\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;evt.time\u0026#34;:1618347519000000,\u0026#34;fd.name\u0026#34;:\u0026#34;/bin/hack\u0026#34;,\u0026#34;proc.cmdline\u0026#34;:\u0026#34;touch /bin/hack\u0026#34;,\u0026#34;user.name\u0026#34;:\u0026#34;root\u0026#34;}}\u0026#39; Falco community also provides a Web UI for following live events an get statistics about last. (Tip: you can add filters by clicking on any label)\nBy default, you can access to it through a port forward too:\nkubectl port-forward svc/falco-falcosidekick-ui -n falco 2802 You now have access in your browser with the URL: http://localhost:2802/ui\nGet involved If you would like to find out more about Falco:\nGet started in Falco.org. Check out the Falco project on GitHub. Get involved Falco community. Meet the maintainers on the Falco Slack. Follow @falco_org on Twitter. And that's it!\nEnjoy\n","summary":"","tags":null,"title":"Extend Falco outputs with falcosidekick","url":"https://v0-43--falcosecurity.netlify.app/blog/extend-falco-outputs-with-falcosidekick/"},{"category":"blog","content":"Another month has passed and Falco continues to grow!\nToday we announce the release of Falco 0.23 🥳\nWondering why this release is called \u0026quot;The Artifacts Scope\u0026quot; release? Please read more here.\nYou can take a look at the whole set of changes here:\n0.23.0 In case you just want to try out the stable Falco 0.23, you can install its packages following the usual process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu Do you rather prefer using the docker images? No problem!\ndocker pull falcosecurity/falco-no-driver:latest # The most recent version docker pull falcosecurity/falco-no-driver:0.23.0 # A specific version of Falco such as 0.23.0 docker pull falcosecurity/falco-driver-loader:latest # The most recent version of falco-driver-loader with the building toolchain docker pull falcosecurity/falco-driver-loader:0.23.0 # A specific version of falco-driver-loader such as 0.23.0 with the building toolchain docker pull falcosecurity/falco:latest # The most recent version with the falco-driver-loader included docker pull falcosecurity/falco:0.23.0 # A specific version of Falco such as 0.23.0 with falco-driver-loader included Please be aware that: we now recommend that instead of using falcosecurity/falco:latest directly, you use the falcosecurity/falco-driver-loader image first, then use the falcosecurity/falco-no-driver:latest. The falcosecurity/falco:latest is going nowhere, we just want to provide a way to do the same thing but splitted into two separate processes to lower the attack surface of the running Falco container. Read more about the images reorganization here.\nBreaking Changes Both in the packages and in the falco-driver-loader script now the kernel module and eBPF probe are referenced as falco.ko and falco.o respectively, before they were falco-probe.ko and falco-probe.o. In the case of Falco installed using the kernel module this can lead to a duplicated module loaded given that the names are different. Make sure you don't have a duplicated module by The falco-driver-loader script environment variable to use a custom repository to download drivers now uses the DRIVERS_REPO environment variable instead of DRIVER_LOOKUP_URL. This variable must contain the parent URI containing the following directory structure /$driver_version$/falco_$target$_$kernelrelease$_$kernelversion$.[ko|o]. Rules update (yay yay! We always improve the default ruleset!!) rule(Redirect STDOUT/STDIN to Network Connection in Container): correct rule name as per rules naming convention rule(Redirect STDOUT/STDIN to Network Connection in Container): new rule to detect Redirect stdout/stdin to network connection in container rule(K8s Secret Created): new rule to track the creation of Kubernetes secrets (excluding kube-system and service account secrets) rule(K8s Secret Deleted): new rule to track the deletion of Kubernetes secrets (excluding kube-system and service account secrets) Some statistics 35 pull requests merged in, 18 of which containing changes directly targeting our end-users.\n72 commits since past release, that was a month ago.\nUpcoming things We are about to merge support for unix sockets in the Falco gRPC API with #1217, more importantly during this release cycle the community made a decision about adopting pdig as a repository (learn here what this means). pdig will allow Falco to run completely in userspace. This is very useful when Falco is deployed in environments where it's not possible to load a kernel module or an eBPF probe. Our community members, already created two projects that can be used to deploy Falco with pdig as a driver, falco-trace and falco-inject. We will look forward to adopting them or making different decisions.\nSee you next month with many more fabulous things!\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.23.0 a.k.a. \"the artifacts scope release\"","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-23-0/"},{"category":"blog","content":"As The Falco Project continues to grow, we are begining to understand the differences in engagement and support for our tooling.\nDrawing on the history of the now deprecated Kubernetes incubator and the CNCF project maturity levels we began to realize that Falco and Falco integrations were reaching a state where we needed to begin separating sub projects from the Falco core components.\nThis of course started by first declaring the scope of The Falco Project. Pull request #1184 aims at doing just that.\nThis introduces the idea of a small core, with a minimal scope for the official supported artifacts. These core artifacts are designed to be the fundamental building blocks that other work can be built on top of. Now that the core components are designed, and documented we can begin to build integrations and third party support on top of these.\nFalco has adopted a familiar 3-tier approach at promoting sub projects, and the support for them through the community. Falco will have 3 main levels that work can be tiered at.\nContrib This is the simplest and easiest way to share work in the Falco community. There is no official support for this level other than \u0026quot;use at your own risk\u0026quot;. The community can still benefit from having an archive of this data, but the project does not have the resources to fully support this archive.\nA contribution here could be as simple as a small amount of documentation, a script, or example configuration. Think convenience scripts, YAML, and markdown pages.\nRepository The main difference between a contribution in Contrib and Repository is that a repository has two main features associated with the work.\nA build and release A github repository These are more involved contributions and are usually in the form of programming languages. These are convenience tooling, utilities, integrations, connectors, etc. Think the Falco Helm charts, the falco-exporter or the falcosidekick.\nThe support for these contributions are handled by a one-off basis and each repository will have an OWNERS file. The maintainers listed in the OWNERS file will be responsible for supporting each of these repositories.\nOfficial The most elite, and coveted of all Falco projects: Official support.\nThis means that the Falco core maintainers have agreed to provide timely releases, and support for these artifacts.\nThese artifacts are ready to be deployed to production and have been giving attention to the following\nSecurity Resilience Stability --\nUnderstanding core components The Falco Project core components are intentionally designed to be small, fundamental artifacts.\nBecause of the complexity and security requirements of running Falco in production these artifacts are clearly labeled and can be composed for various use cases.\nFor instance. The Falco Project core supports various container images which require different access to the system in order to run effectively. These container images can be composed with YAML manifests or other management tools like Helm or Kustomize. The higher level compositions are not currently considered part of Falco core, as they make assumptions on behalf of the user.\nThe Falco community is supporting various repository level work around these higher level compositions such as the charts repository and falcoctl.\nEach of these higher level tools, can then begin to craft opinionated compositions of Falco components such as secure by defualt or convenient.\nAs these compositions are hardened and can demonstrate maintainer support and usage, they will then be promoted to official support as needed.\n","summary":"","tags":null,"title":"The Scope of Falco","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-scope/"},{"category":"blog","content":"Another month has passed and Falco continues to grow!\nToday we announce the release of Falco 0.22 🥳\nYou can take a look at the whole set of changes here:\n0.22.0 - thanks to Leonardo Grasso for his first ever release! 0.22.1 - hotfix by me and Lorenzo Fontana In case you just want to try out the stable Falco 0.22, you can install its packages following the usual process outlined in the docs:\nCentOS/Amazon Linux Debian/Ubuntu Do you rather prefer using the docker images? No problem!\ndocker pull falcosecurity/falco:0.22.1 docker pull falcosecurity/falco:0.22.1-minimal docker pull falcosecurity/falco:0.22.1-slim Notable Changes This release comes with a lot of fixes for longstanding tough bugs!\nBut also with some new features 😊\nIn case you are managing the Falco drivers yourself please make sure to update them to version a259b4bf49c3330d9ad6c3eed9eb1a31954259a6 (reference here).\neBPF driver Some users reported a problem in getting the eBPF driver to work on GKE.\nThis release finally introduces a fix for it.\nvalues Some users reported they were getting \u0026lt;NA\u0026gt; values for docker and Kubernetes metadata in the alerts.\nWith the following pull requests, falco#1133, falco#1138, and falco#1140, the problem should now be definitely fixed, as reported by the users testing the development release of Falco containing the fixes.\nFalco version and driver version are now distinct! Going through the process of a better modularization for Falco, now the Falco version and the version of its drivers are two distinct things finally!\nClearly, in order to obtain this some PRs were needed 😝 both in the packagin system and in the falco-driver-loader script.\nfalco#1111 falco#1148 Rules, rules everywhere! This release also had a lot of rule changes. Most notably vicenteherrera created many new rules:\nFull K8s Administrative Access Ingress Object without TLS Certificate Created Untrusted Node Successfully Joined the Cluster Untrusted Node Unsuccessfully Tried to Join the Cluster Network Connection outside Local Subnet Outbound or Inbound Traffic not to Authorized Server Process and Port Thanks Vicente! 🙌🏻\nSynchronous CRI metadata fetch Thanks to PR falco#1099 users can now disable the asynchronous fetching of CRI metadata forcing it to be synchronous.\nTo do it, just pass the --disable-cri-async flag to Falco.\nWhile this can slow down Falco event processing and can cause drop rate to raise, it helps in getting less null values for containers metadata.\nBefore using this flag, please try out this release since it contains other fixes for this topic!\nSome statistics 23 pull requests merged in, 18 of which containing changes directly targeting our end-users.\n49 commits since past release, in 30 days.\nUpcoming things The drivers build grid is almost ready.\nJust some missing refinements and then Falco will have again a set of prebuilt drivers (both kernel modules and eBPF probes) to be downloaded during the installation!\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.22 a.k.a. \"the hard fixes release\"","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-22-x/"},{"category":"blog","content":"Kind is a tool for running local Kubernetes clusters using Docker container \u0026quot;nodes\u0026quot;, that may be used for local development or CI. It also offers a convenient and easy way to install Falco in a Kubernetes cluster and play with it locally. We will use Kind to show how to export Falco metrics to Prometheus and Grafana.\nCreate a Kind cluster Running Falco in a Kind cluster is easy, as explained in the documentation.\nIf you want to use the kernel module, basically, you only have to mount /dev.\nNote that it's not mandatory to mount the entire /dev path. Falco just needs access to some devices created by the kernel module:\n$ ls -l /dev/falco* cr-------- 1 root root 238, 0 Mar 12 16:04 /dev/falco0 cr-------- 1 root root 238, 1 Mar 12 16:04 /dev/falco1 cr-------- 1 root root 238, 2 Mar 12 16:04 /dev/falco2 cr-------- 1 root root 238, 3 Mar 12 16:04 /dev/falco3 cr-------- 1 root root 238, 4 Mar 12 16:04 /dev/falco4 cr-------- 1 root root 238, 5 Mar 12 16:04 /dev/falco5 cr-------- 1 root root 238, 6 Mar 12 16:04 /dev/falco6 cr-------- 1 root root 238, 7 Mar 12 16:04 /dev/falco7 As you can see, the kernel module is creating one device per CPU (8 in my case). These paths are all Falco needs.\nCertificates To export metrics to Prometheus, we will use falco-expoter which connects to the Falco gRPC output. The Falco gRPC server works only with mutual TLS by design. Therefore, you also need valid certificate files to configure Falco and falco-exporter properly.\nYou can quickly generate cert materials using falcoctl:\nFALCOCTL_NAME=falco-grpc.default.svc.cluster.local FALCOCTL_PATH=/tmp/certs falcoctl install tls Otherwise you can manually generate them as explained here.\nNote that in both cases, you have to make sure to set the correct CommonName. In this example, we are using the default hostname used by the Helm chart.\nInstall Falco The official Falco Helm Chart is a straightforward way to deploy Falco. The chart adds Falco to all nodes in your cluster using a DaemonSet.\nEnable the Falco charts repository:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update Be sure to include TLS cert material and enable the gRPC output:\nhelm install falco falcosecurity/falco \\ --set-file certs.server.key=/tmp/certs/server.key,certs.server.crt=/tmp/certs/server.crt,certs.ca.crt=/tmp/certs/ca.crt \\ --set falco.grpc.enabled=true,falco.grpcOutput.enabled=true Install falco-exporter falco-exporter is the Prometheus metrics exporter for Falco output events. Again here, using the provided Helm chart is the easiest way to deploy it.\nSo you only have to run the helm install command:\nhelm install falco-exporter \\ --set-file certs.ca.crt=/tmp/certs/ca.crt,certs.client.key=/tmp/certs/client.key,certs.client.crt=/tmp/certs/client.crt \\ falcosecurity/falco-exporter Install Prometheus Once Falco and the exporter are up and running, we can proceed by installing Prometheus:\nhelm install prom stable/prometheus Then we have to wait for Prometheus to set up and run:\nexport POD_NAME=$(kubectl get pods --namespace default -l \u0026#34;app=prometheus,component=server\u0026#34; -o jsonpath=\u0026#34;{.items[0].metadata.name}\u0026#34;) kubectl --namespace default port-forward $POD_NAME 9090 So we can open http://localhost:9090/targets and check that falco-exporter has been discovered by Prometheus.\nInstall Grafana and the Falco dashboard To deploy Grafana, just run:\nhelm install grafana stable/grafana Then get your 'admin' user password by running:\nkubectl get secret --namespace default grafana -o jsonpath=\u0026#34;{.data.admin-password}\u0026#34; | base64 --decode ; echo When Grafana is up and running, port forward the Grafana service:\nkubectl port-forward service/grafana 3000:80 To log in to Grafana, open http://127.0.0.1:3000/login and use the 'admin' user password you got above.\nNow you can add the Prometheus endpoint (http://prom-prometheus-server.default.svc.cluster.local) to the Grafana data sources and finally go to http://127.0.0.1:3000/dashboard/import and import the Falco dashboard by copy-paste the following dashboard URL:\nhttps://grafana.com/grafana/dashboards/11914 Otherwise, you can use the provided dashboard.json.\nNow we can generate events to see the system in action!\nGenerate events There are many ways to demonstrate a Falco rule has been violated, and if you have loaded the default Falco ruleset here are some fun things to try.\nA simple one line example is to create an alert is to touch a file in a well known executable directory. Also, you can cat or touch files in other potentially vulnerable directories as well.\nCommon one-liners touch /usr/local/bin/example-violation touch /usr/bin/example-violation cat /etc/shadow touch /etc/example-violation You can find the default ruleset here.\nFun with privileged mode You can see the demo that Kris Nóva gave at FOSDEM and find the function shell() that she used defined below.\nfunction shell () { kubectl run shell --restart=Never -it --image krisnova/hack:latest \\ --rm --attach \\ --overrides \\ \u0026#39;{ \u0026#34;spec\u0026#34;:{ \u0026#34;hostPID\u0026#34;: true, \u0026#34;containers\u0026#34;:[{ \u0026#34;name\u0026#34;:\u0026#34;scary\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;krisnova/hack:latest\u0026#34;, \u0026#34;imagePullPolicy\u0026#34;: \u0026#34;Always\u0026#34;, \u0026#34;stdin\u0026#34;: true, \u0026#34;tty\u0026#34;: true, \u0026#34;command\u0026#34;:[\u0026#34;/bin/bash\u0026#34;], \u0026#34;nodeSelector\u0026#34;:{ \u0026#34;dedicated\u0026#34;:\u0026#34;master\u0026#34; }, \u0026#34;securityContext\u0026#34;:{ \u0026#34;privileged\u0026#34;:true } }] } }\u0026#39; } You can paste this into a new file shell.sh and source the file.\nsource shell.sh Then you can type the following to demonstrate a privilege escalation in Kubernetes.\n[user@user]$ shell If you don\u0026#39;t see a command prompt, try pressing enter. root@shell:/# nsenter -t 1 -m -u -i -n bash root@ip-1-2-3-4:/# Doing this takes advantage of a well known security exploit in Kubernetes, and you can find the Falco alerts rendered in Prometheus/Grafana.\nFalco events generator You can find more information on generating sample events in the official documentation\nFor a quick example, you can run the following command to begin generating events\ndocker run -it --rm falcosecurity/event-generator run syscall --loop ","summary":"","tags":null,"title":"Falco on Kind with Prometheus and Grafana","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-kind-prometheus-grafana/"},{"category":"blog","content":"Even though there's the lockdown, Falco 0.21.0 decided to go out! Such a bad guy!\nNotably, this is the first release that happens with the new build \u0026amp; release process. 🚀\nIn case you just want Falco 0.21.0, you can find its packages at the following repositories:\nhttps://bintray.com/falcosecurity/rpm/falco/0.21.0 https://bintray.com/falcosecurity/deb/falco/0.21.0 https://bintray.com/falcosecurity/bin/falco/0.21.0 Instructions to install using them are already updated on the Falco website:\nCentOS/Amazon Linux Debian/Ubuntu Instead, for people preferring docker images... 🐳\ndocker pull falcosecurity/falco:0.21.0 docker pull falcosecurity/falco:0.21.0-minimal docker pull falcosecurity/falco:0.21.0-slim Notable Changes Release #100 of Falco comes with some notable changes.\nNew release process in place During past weeks, I worked together with Lorenzo to put in place a completely new and automated release process for Falco.\nWe did most of the work into PR 1059.\nThis process takes place in two cases:\nA pull request is merged into master, which leads to the release of a development version of Falco A commit on master receives a git tag, which leads to the release of a stable version of Falco When one of these two conditions happen:\nit packages Falco into signed (GPG public key) packages: DEB, a RPM, and a TAR.GZ it pushes these packages to their new open repositories deb-dev, rpm-dev, bin-dev for development versions deb, rpm, bin for stable versions it builds the docker images from these packages it pushes the docker images to the docker hub falcosecurity/falco:master, falcosecurity/falco:master-slim, falcosecurity/falco:master-minimal for development versions falcosecurity/falco:latest, falcosecurity/falco:latest-slim, falcosecurity/falco:latest-minimal for stable versions March 2021 update: All packages are now published to download.falco.org.\nFALCO_BPF_PROBE Thanks to Lorenzo contribution (PR 1050), to make Falco use the eBPF probe as a driver you need to specify an environment variable named FALCO_BPF_PROBE, not SYSDIG_BPF_PROBE anymore.\nFALCO_BPF_PROBE=\u0026#34;\u0026#34; ./build/release/userspace/falco/falco -r ... Please update your systemd scripts or Kubernetes deployments.\nFalco versions are now SemVer 2.0 compliant In PR 1086, I completed the process of creating the Falco version as SemVer 2.0 compliant version strings, from the git index.\nThis PR introduces the pre-release part into Falco versions.\nNow Falco versions are something like 0.21.0-3+c5674c9, where 3 is the number of commits since the latest stable version (0.21.0) of Falco, while c5674c9 is the commit hash of the current development version.\nPlease notice that the Falco gRPC version API already contains this version part, too.\nDetect outbound connections to common miner pool ports rule disabled by default Thanks to Khaize work in PR 1061 users will not be hit from a tedious amount of alerts about hypothetical mining tools.\nFrom now on, this rule is disabled by default.\nAlso, if it is enabled by you, it will ignore localhost and RFC1918 addresses.\nOther changes You can read the full changelog here!\nSome statistics 19 PRs merged in, 12 of which containing changes targeting end-users.\n64 commits since past release, in 17 days.\nUpcoming things Stay tuned for the upcoming drivers build grid which, using driverkit - a quarantine project by me and Lorenzo - will pre-build and release (in the open too!) the Falco kernel modules and the Falco eBPF probes for a set of predefined target systems and kernel releases.\n","summary":"","tags":["Falco","Release"],"title":"Falco 0.21.0 is out!","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-21-0/"},{"category":"blog","content":"Minikube is a tool that implements a local Kubernetes cluster on macOS, Linux and Windows via a simple command line, it is vastly used by community members who want to try Falco as well by Falco contributors who want to develop and debug it against new and old Kubernetes versions.\nNow, thanks to Anders Björklund who proposed PR#6560 every user starting any Kubernetes cluster using Minikube \u0026gt;= 1.8.0 (with the minikube iso, e.g: using a VM driver) will also find installed a copy of the Falco kernel module ready to serve Falco instances in user-space!\nAt the moment of writing, Minikube installs Kubernetes 1.17.3, and the Falco repository does not yet ship the manifests containing the new changes for Kubernetes \u0026gt;= 1.16, although there are PRs #1044 and #1005 that go to that direction.\nFor this reason, to test this you can either just patch the manifests yourself or use the Falco Helm Chart that was already patched and works in this case!\nIt is extremely easy! After installing Minikube 1.8.0 you only need to start a cluster and install Falco using the Helm Chart.\nCreate the cluster with Minikube using a VM driver, in this case Virtualbox:\nminikube start --driver=virtualbox Once you issue the command, look at the logs to make sure you have at least Minikube 1.8.0:\n😄 minikube v1.8.1 on Arch ▪ KUBECONFIG=/home/fntlnz/.kube/current ✨ Automatically selected the virtualbox driver 💿 Downloading VM boot image ... 🔥 Creating virtualbox VM (CPUs=2, Memory=3939MB, Disk=20000MB) ... 🐳 Preparing Kubernetes v1.17.3 on Docker 19.03.6 ... 🚀 Launching Kubernetes ... 🌟 Enabling addons: default-storageclass, storage-provisioner ⌛ Waiting for cluster to come online ... 🏄 Done! kubectl is now configured to use \u0026#34;minikube\u0026#34; Now that our VM is ready, we can SSH into it to verify that the module is there!:\nminikube ssh Once we are in:\nlsmod | grep -i falco Aaaand..... It will show nothing! Because the Falco module has not been loaded yet!\nLet's continue with the installation of Falco, it will load the module for us afterwards.\nVerify that everything is running, it will need to show the system pods:\nkubectl get pods --all-namespaces Add the Stable chart repository to Helm:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update Install Falco using Helm:\nhelm install falco falcosecurity/falco It will give something like this:\nNAME: falco LAST DEPLOYED: Sun Mar 8 16:29:11 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Falco agents are spinning up on each node in your cluster. After a few seconds, they are going to start monitoring your containers looking for security issues. No further action should be required. Read the logs to make sure Falco is running!\nkubectl logs -l app=falco -f It will show errors trying to find the Kernel headers, those are needed to build the module but we can just skip those errors because the module is already there!\n* Unloading falco-probe, if present * Running dkms install for falco Error! echo Your kernel headers for kernel 4.19.94 cannot be found at /lib/modules/4.19.94/build or /lib/modules/4.19.94/source. * Running dkms build failed, couldn\u0026#39;t find /var/lib/dkms/falco/0.20.0+d77080a/build/make.log * Trying to load a system falco-probe, if present falco-probe found and loaded with modprobe Sun Mar 8 15:29:55 2020: Falco initialized with configuration file /etc/falco/falco.yaml Sun Mar 8 15:29:55 2020: Loading rules from file /etc/falco/falco_rules.yaml: Sun Mar 8 15:29:56 2020: Loading rules from file /etc/falco/falco_rules.local.yaml: Sun Mar 8 15:29:56 2020: Starting internal webserver, listening on port 8765 Now that Falco is running, we can go and check if the module was loaded, again after doing minikube ssh:\nsudo lsmod| grep -i falco It will finally show that the Falco module is loaded!\nfalco_probe 630784 2 You're done! You're ready to start doing great contributions to Falco and to make a difference in our community!\nWe need help on many things right now:\nFalcoctl the Falco command line, needs some love from Go developers to improve the Falco command line and automate maintainance and usage tasks; Driverkit the new Falco tool to build the Falco driver needs help from Go developer and Kernel hackers to support more Operating systems and architectures; client-rs needs Rust developers to support the latest gRPC APIs our community developed, like the Version API, see the similar PR on client go to understand what we mean here Falco itself needs C++ developers and Kernel hackers to fix bugs, make features more stable, add tests, and further improvements! Please join us! And you? What do you want to hack on this week? Reach us in the Falco mailing list subscribe on Falco.org by scrolling all the way down and input your email address.\n","summary":"","tags":null,"title":"Minikube 1.8.0 packages the Falco Kernel Module","url":"https://v0-43--falcosecurity.netlify.app/blog/minikube-falco-kernel-module/"},{"category":"blog","content":"We're pleased to announce the release of Falco 0.20.0, our second release of 2020! Falco 0.20.0 consists of a major bug fix, a new feature, two minor bug fixes, and seven rules changes.\nA total of eight people contributed to this release with a total of thirteen Pull Requests merged in!\nEveryone is encouraged to update Falco now, especially if you are running Falco 0.18.0 or Falco 0.19.0 and are using Kubernete Audit Events.\nThe full changelog can be found here.\nMajor themes Memory leaks in Kubernetes Audit Events Upgrading is particularly important because the versions above are subject to a memory leak that has been reported by many users both on GitHub and Slack.\nIn particular, the reports had situations like this one:\nYou can see how Falco was OOM killed by the cluster after increased memory usage due to this bug.\nAfter some analysis, we noticed the leak was due to some misconfiguration in how we handled a parameter in the JSON events filters.\nThe analysis was done by analyzing the Valgrind Massif tool and using massif-visualizer it was immediately clear that a leak was going on.\nFor those interested, you can check this yourself by executing Falco with massif, in this way:\nsudo valgrind --tool=massif --threshold=0.1 ./build/userspace/falco/falco -c falco.yaml -r rules/falco_rules.yaml -r rules/k8s_audit_rules.yaml -r rules/falco_rules.local.yaml -M 100 Version API Many users requested to be able to check the Falco version while using the Outputs API.\nIn Falco 0.20.0 there's a new API called Version API that you can use to gather various information about the version of the running Falco.\nWhen using the Falco Go Client you can retrieve the version in this way:\n// Set up a connection to the server. c, err := client.NewForConfig(\u0026amp;client.Config{ Hostname: \u0026#34;localhost\u0026#34;, Port: 5060, CertFile: \u0026#34;/tmp/client.crt\u0026#34;, KeyFile: \u0026#34;/tmp/client.key\u0026#34;, CARootFile: \u0026#34;/tmp/ca.crt\u0026#34;, }) if err != nil { log.Fatalf(\u0026#34;unable to create a Falco client: %v\u0026#34;, err) } defer c.Close() versionClient, err := c.Version() if err != nil { log.Fatalf(\u0026#34;unable to obtain a version client: %v\u0026#34;, err) } ctx := context.Background() // Retrieve the version res, err := versionClient.Version(ctx, \u0026amp;version.Request{}) Here there's a full example you can checkout and run.\nMinor themes Bug Fixes fix: the base64 output format (-b) now works with both json and normal output. [#1033] fix: version follows semver 2 bnf [#872] Rule Changes rule(write below etc): add \u0026quot;dsc_host\u0026quot; as a ms oms program [#1028] rule(write below etc): let mcafee write to /etc/cma.d [#1028] rule(write below etc): let avinetworks supervisor write some ssh cfg [#1028] rule(write below etc): alow writes to /etc/pki from openshift secrets dir [#1028] rule(write below root): let runc write to /exec.fifo [#1028] rule(change thread namespace): let cilium-cni change namespaces [#1028] rule(run shell untrusted): let puma reactor spawn shells [#1028] ","summary":"","tags":["Falco","Release"],"title":"Falco 0.20.0 is released","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-0-20-0/"},{"category":"blog","content":"Regularly auditing a code base is an important process in releasing secure software. Audits can be particularly important for open source projects that rely on code from a wide variety of contributors. We are happy to announce the release of Falco’s first security audit which was performed through Falco’s participation as a CNCF Sandbox project. A big thanks to the CNCF for sponsoring the audit, and to the Cure53 team who performed the audit.\nOverall the security audit discovered 3 potential vulnerabilities (1 Critical, 2 High) and 2 miscellaneous issues (Low). You can find the details of the audit and the vulnerabilities in the full published report (pdf). Below you can find a brief description of each vulnerability, and the implemented remediation. In addition to the implemented remediations, these issues have helped us better understand how the Falco team can refactor the Falco architecture to reduce the chance of security vulnerabilities.\nUsers are encouraged to upgrade to Falco 0.18.0 which contains fixes for each of the issues below.\nVulnerabilities Discovered FAL-01-001 Driver: Undetected crash disables Falco monitoring (Critical) In addition the the Falco audit, Sysdig (the company) sponsored a similar audit for sysdig OSS (the open source project). Currently Falco has a direct dependency on sysdig OSS, in particular Falco leverages the libscap, libsinsp, kernel module, and eBPF probe. FAL-01-001 addresses a vulnerability where the kernel module could crash due to an integer overflow. The libscap and libsinsp libraries did not detect the crashed kernel module, and thus this disabled the stream of system calls Falco uses to detect abnormal behavior.\nFAL-01-002 Falco: Bypassing various rules with different techniques (High) This vulnerability covers various methods in which rules can be bypassed. The Cure53 found that various assumptions that were made in the default set of Falco rules ignored several edge cases which allowed rules to be bypassed. Changes were made to the default rules to better detect these edge cases, and the Falco community is constantly updating the default rules to address various edge cases such as found in the audit.\nFAL-01-003 Falco: HTTP request with incorrect data leads to crashes (High) Falco includes an embedded HTTPs server to serve as a backend for Kubernetes Audit Log events. The request handler for this web server expects JSON formatted data. Cure53 discovered that the request handler was not properly checking the incoming request for properly formatted JSON. Additionally the request handler was not properly checking the type (integer, string, etc) of incoming data. This caused the Falco daemon to crash, and disables the protection Falco provides until the Falco daemon is restarted by systemd or Kubernetes.\nMiscellaneous Issues FAL-01-004 Falco: Dependencies pulled via hard-coded HTTP links (Low) Falco leverages cmake for building Falco and its dependencies. As part of this process, cmake will download the required dependencies if they are not made available by the local operating system. For some of the dependencies, cmake was using HTTP rather than HTTPs to download the dependencies. In theory, this would allow an attacker to perform a man-in-the-middle attack to replace the downloaded packages with a malicious package. However, in practice, cmake also verifies the SHA256 sum of downloaded dependencies to protect against MITM attacks.\nFAL-01-005 Falco: Security flags not enforced by Makefile (Low) Modern compilers provide flags that can reduce the likelihood of memory corruption based attacks. Falco does not explicitly set these flags in the project’s CMakeLists.txt. In order to implement these flags, Falco requires upstream dependencies (namely sysdig OSS) to support them the flags as well. The Falco team is working to implement these changes with the sysdig OSS project team.\nAs part of the Falco team’s continuing focus on improving the security of the project, we’ve also published a security vulnerability reporting process. We once again would like to thank the CNCF for sponsoring the Falco security audit and the Cure53 team for executing the audit. Having CNCF projects go through these security audits allows for projects to build and release more secure software, and serves to provide confidence in the projects that are part of the CNCF. We look forward to repeating this process periodically, and we invite anyone in the Falco community to participate in future audits.\n","summary":"","tags":null,"title":"Falco Security Audit","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-security-audit/"},{"category":"blog","content":"Falco rules management The Falco community is excited to announce that we will be optimizing how we manage and install security rules for the Falco engine to assert.\nWe have published an open source repository of common security rules that can be used with Falco. You can check out the rules dynamically rendered on securityhub.dev.\nInstalling a rule In this quick example we will be adding runtime detection for CVE-2019-11246.\nUnderstanding Rules Notice how the meta information found in the repository matches up with the data rendered on the security hub page for CVE-2019-11246\nCurrently we support helm upgrade as well as raw YAML for rules.\nInstalling with Helm If you are using helm to install and manage Falco you can mutate the configuration using friendly helm commands. In this example we use -f to append our falco installment with a rule from the repository.\nhelm upgrade falco -f https://api.securityhub.dev/resources/cve-2019-11246/custom-rules.yaml stable/falco Installing with raw YAML You can click the yaml button in the repository website to view the raw YAML for the rule:\n- macro: safe_kubectl_version condition: (jevt.value[/userAgent] startswith \u0026#34;kubectl/v1.19\u0026#34; or jevt.value[/userAgent] startswith \u0026#34;kubectl/v1.18\u0026#34; or jevt.value[/userAgent] startswith \u0026#34;kubectl/v1.17\u0026#34; or jevt.value[/userAgent] startswith \u0026#34;kubectl/v1.16\u0026#34; or jevt.value[/userAgent] startswith \u0026#34;kubectl/v1.15\u0026#34; or jevt.value[/userAgent] startswith \u0026#34;kubectl/v1.14.3\u0026#34; or jevt.value[/userAgent] startswith \u0026#34;kubectl/v1.14.2\u0026#34; or jevt.value[/userAgent] startswith \u0026#34;kubectl/v1.13.7\u0026#34; or jevt.value[/userAgent] startswith \u0026#34;kubectl/v1.13.6\u0026#34; or jevt.value[/userAgent] startswith \u0026#34;kubectl/v1.12.9\u0026#34;) # CVE-2019-11246 # Run kubectl version --client and if it does not say client version 1.12.9, 1.13.6, or 1.14.2 or newer, you are running a vulnerable version. - rule: K8s Vulnerable Kubectl Copy desc: Detect any attempt vulnerable kubectl copy in pod condition: kevt_started and pod_subresource and kcreate and ka.target.subresource = \u0026#34;exec\u0026#34; and ka.uri.param[command] = \u0026#34;tar\u0026#34; and not safe_kubectl_version output: Vulnerable kubectl copy detected (user=%ka.user.name pod=%ka.target.name ns=%ka.target.namespace action=%ka.target.subresource command=%ka.uri.param[command] userAgent=%jevt.value[/userAgent]) priority: WARNING source: k8s_audit tags: [k8s] You can then install using the supported Falco parlance defined in the official documentation.\nWe have plans to take it a step further with our new CLI tool falcoctl that is currently in an alpha state. Some basic features we are looking to build\nCLI style interface for managing falco rules (install, get, update, remove) Authentication of rules using hashing and well-known keys in a repository Documentation on how to build your own repository Gitops style workflow Keep reading to find out more on how to get involved and contribute, especially if you have ideas. We would love to hear them.\nGetting involved The project was originally started by Sysdig, but maintaining the repositories, and building out rules will now be governed by the CNCF and the Falco community.\nIf you are interested in getting involved with writing rules, or building out tooling around the new hub please reach out to The official CNCF Falco Mailing List or join the Falco slack channel.\nIntegrating with Falcoctl We are currently in the process of building out command line tooling for managing security hub rules with falcoctl.\nIf you write Go, and are interested in joining in the effort of building out a management experience for users, we would love to collaborate with you! Please reach out using the links above and we can get started.\nWe have proposed some changes to the falcoctl code base to begin work on using falcoctl to manage rules.\nIf reading about this gets you excited, and you would be interested in collaborating we would love to talk more.\nCall for maintainers Furthermore if you are interested in getting directly involved with CNCF open source, and would like a shot at becoming a maintainer please reach out using the links above. You will have a chance to work directly with the Falco team, and the Falco community. As well as have ownership over a cutting edge security tool.\nContributing rules The anatomy of a Falco rule for the security hub is as follows:\napiVersion: v1 kind: FalcoRules name: CVE-2020-12345 shortDescription: What does this rule do? Why is it useful? version: 1.0.0 description: | # Here is valid markdown Add *anything* you want and it will be rendered on the security hub! keywords: - falco, rule, awesome icon: https://cve.mitre.org/images/cvebanner.png maintainers: - name: Kris Nova link: https://github.com/kris-nova rules: - raw: | # Here is a valid Lua rule for Falco Please open up a PR to the security hub repository with a new rule matching the syntax defined above.\n","summary":"","tags":null,"title":"Cloud Native Security Hub","url":"https://v0-43--falcosecurity.netlify.app/blog/cloud-native-security-hub/"},{"category":"blog","content":"We are pleased to announce that falcosidekick, a Go project aimed to forward Falco outputs to a number of services, joined the falcosecurity organization on GitHub.\nAlong with the project, we also want to welcome Thomas Labarussias, the creator of falcosidekick joining us as maintainer of the Falco project starting from now on.\nThe joining of this project and of Thomas as maintainer is part of a continued effort of involving more people in the Falco project and to get Falco more and more extensible and consumable.\nBut there’s other news, too!\nWe want to improve even more how outputs go over the wire by introducing a gRPC interface with a clear protocol, you can tell us what you think by reviewing the current proposal and making changes right now!\nStay tuned, and join us at the Falco Office Hours on Wednesday September 4th!\nYou can propose the topics to discuss by opening an issue in the Falco Office Hours repository and we will discuss them during the call.\nHere you can find and subscribe to the Falco calendar to stay tuned!\n","summary":"","tags":null,"title":"falcosidekick joins the falcosecurity organization","url":"https://v0-43--falcosecurity.netlify.app/blog/falcosideckick-joins-falcosecurity/"},{"category":"blog","content":"One of the most successful aspects of Kubernetes is how functional the open source community was able to operate. Kubernetes broke itself down in smaller sections called special interest groups, that operate similarly to subsections of the kernel. Each group is responsible for a single domain, and sets their own pace. One of the most important things to a Kubernetes SIG, is the residual SIG calls. These are important opportunities for engineers across the industry to come together regardless of their employment status to work on building software. The structure of a SIG call varies from group to group, but all calls exist to organize the engineers working in a particular space.\nThe call begins, and users sign in so we can track attendance over time. We have a pre-loaded agenda that everyone can edit in between the calls. We work through the agenda item by item, taking note of any action that comes from our time together. The theory is that the calls are were we make decisions as a team, and decisions shouldn’t be made without giving everyone in the SIG an opportunity to voice their opinion. Its remarkable how even this small amount of structure has enabled thousands of engineers in the community to work together in a productive and inclusive way.\nWe want to embrace this philosophy with Falco Every Wednesday morning at 8am Pacific we invite everyone in the Falco community to join our open source calls. We switch off the meeting objective every week. It alternates between an “office hours” call, and a “repository planning” call. You can get calendar invites to each of these calls by joining the official Falco mailing list. We hope you are as excited as we are about moving Falco to full time open source, and we hope to see you during the meetings!\nFalco office hours This is an open ended call where we discuss feature work and open issues from the issue tracker. More information can be found here in the official Falco office Hours repository. This call is structured in a way to enable the users of Falco. As a Falco user, joining this call would be a good place to ask questions or get involved with the project.\nRepository planning These calls are structured for engineers working on Falco. This is where we discuss the future of Falco, and assign items to engineers. All of our roadmap planning happens on these calls. This is the best way to get feature work out of Falco.\n","summary":"","tags":null,"title":"Falco in the open","url":"https://v0-43--falcosecurity.netlify.app/blog/falco-in-the-open/"},{"category":"docs","content":"For some Integrated Development Environment (IDE) Editors, there is support for falco rules files that allow for on-the-fly syntax checking and validation of rules content.\nEmacs For emacs, there is a Flycheck checker called flycheck-falco-rules:\n","summary":"","tags":null,"title":"IDE Support","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/ide-support/"},{"category":"docs","content":"From time to time, we make changes to the rules file format that are not backwards-compatible with older versions of Falco. Similarly, libsinsp and libscap may define new filtercheck fields, operators, etc. We want to denote that a given set of rules depends on the fields/operators from those libraries.\nThere are currently two optional fields in the falco rules file related to versioning:\nElement Description required_engine_version Used to track compatibility between rules content and the falco engine version. required_plugin_versions Used to track compatibility between rules content and plugin versions. Falco Engine Versioning The falco executable and the falco_engine C++ object now support returning a version number. The initial version is 2 (implying that prior versions were 1). We will increment this version whenever we make an incompatible change to the rules file format or add new fields, events or syntax elements to Falco. You can check the Falco engine version that your installation supports by running falco --version.\nFalco Rules File Versioning The Falco rules files included with Falco include a new top-level object, required_engine_version: N, that specifies the minimum engine version required to read this rules file. If not included, no version check is performed when reading the rules file. Here's an example:\n# This rules file requires a falco with falco engine version 7. - required_engine_version: 7 If a rules file has an engine_version greater than the Falco engine version, the rules file is loaded and an error is returned.\nOfficial Rules File Versioning If you use the official rules distributed by the Falco organization, they are versioned in the repository along with the relevant changelog.\n","summary":"","tags":null,"title":"Rule Format Version","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/versioning/"},{"category":"docs","content":" \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.43.0-rc2\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.43.0-rc2\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.43.0-rc1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.43.0-rc1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.42.1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.42.1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.22.2\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.22.2-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 tgz-static-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.42.1 docker pull public.ecr.aws/falcosecurity/falco:0.42.1 docker pull docker.io/falcosecurity/falco-driver-loader:0.42.1 docker pull docker.io/falcosecurity/falco-driver-loader:0.42.1-buster docker pull docker.io/falcosecurity/falco:0.42.1-debian v0.42.1 Released on 2025-11-06\nNon user-facing changes docs(CHANGELOG.md): update changelog for 0.42.0 release [#3730] - @leogr Statistics MERGED PRS NUMBER Not user-facing 1 Release note 0 Total 1 Release Manager @leogr \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.42.0\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.42.0\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.22.1\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.22.1-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 tgz-static-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.42.0 docker pull public.ecr.aws/falcosecurity/falco:0.42.0 docker pull docker.io/falcosecurity/falco-driver-loader:0.42.0 docker pull docker.io/falcosecurity/falco-driver-loader:0.42.0-buster docker pull docker.io/falcosecurity/falco:0.42.0-debian v0.42.0 Released on 2025-10-22\nMajor Changes feat: add falco_libs.thread_table_auto_purging_interval_s and thread_table_auto_purging_thread_timeout_s configuration options [#3670] - @ekoops feat: log plugin version info at loading time [#3657] - @FedeDP feat: ability to add statically defined fields via static_fields configuration [#3557] - @FedeDP feat(engine): emit warning when a rule containing the evt.dir field in output is encountered [#3697] - @irozzo-1A feat(engine): emit warning when a rule containing a condition on the deprecated evt.dir field is encountered [#3690] - @irozzo-1A new: ability to record .scap files (capture feature) [#3645] - @leogr new(docker): includes sha on the image labels [#3658] - @jcchavezs new(cmake,userspace,ci): add mimalloc support [#3616] - @FedeDP Minor Changes docs(falco.yaml): refactor config documentation [#3685] - @leogr build: fix debian:buster apt debian repo URL in :driver-loader-buster container image [#3644] - @ekoops build: updagrade libs to version 0.22.1 [#3705] - @irozzo-1A build: upgrade drivers to v9.0.0+driver [#3701] - @irozzo-1A build: upgrade cpp-httplib to v0.23.1 [#3647] - @FedeDP update: upgrade default ruleset to v5.0.0 [#3700] - @leogr build: upgrade falcoctl to v0.11.4 [#3694] - @leogr chore(prometheus): deprecate enter events drop stats [#3675] - @irozzo-1A Bug Fixes fix(cmake): correct abseil-cpp for alpine build [#3598] - @RomanenkoDenys fix: enable handling of multiple actions configured with syscall_event_drops.actions [#3676] - @terror96 fix: disable dry-run restarts when Falco runs with config-watching disabled [#3640] - @Proximyst Non user-facing changes fix(userspace/falco): correct default duration calculation [#3715] - @leogr chore(falcoctl): update falco rules to version 5 [#3712] - @irozzo-1A doc(OWNERS): move incertum (Melissa Kilby) to emeritus_approvers [#3605] - @incertum update(cmake): update libs and driver to latest master [#3689] - @github-actions[bot] chore(docker): use new ENV syntax in place of deprecated one [#3696] - @ekoops chore(cmake/modules): update rules to 5.0.0-rc1 [#3698] - @leogr fix(userspace/engine): fix logger date format [#3672] - @ekoops docs(OWNERS): add ekoops(Leonardo Di Giovanna) as approver [#3688] - @ekoops update(cmake): update libs and driver to latest master [#3665] - @github-actions[bot] Refactor: cppcheck cleanups [#3649] - @sgaist update(userspace/engine): update falco engine version and checksum [#3648] - @ekoops update(cmake): update libs and driver to latest master [#3662] - @github-actions[bot] update(cmake): update libs and driver to latest master [#3661] - @github-actions[bot] update(cmake): update libs and driver to latest master [#3653] - @github-actions[bot] chore(ci): disable mimalloc for master builds. [#3655] - @FedeDP chore(deps): Bump submodules/falcosecurity-rules from 1208816 to be38001 [#3651] - @dependabot[bot] docs(falco.yaml): avoid out-of-sync config options for container pl… [#3650] - @leogr update(cmake): update libs and driver to latest master [#3636] - @github-actions[bot] update(CHANGELOG.md): release 0.41.3 (cherry-pick) [#3634] - @ekoops update(cmake): update libs and driver to latest master [#3628] - @github-actions[bot] update(CHANGELOG.md): release 0.41.2 (cherry-pick) [#3623] - @ekoops update(cmake): update libs and driver to latest master [#3618] - @github-actions[bot] update(cmake): update libs and driver to latest master [#3602] - @github-actions[bot] chore(falco.yaml): clean up plugins config leftover [#3596] - @leogr chore(deps): Bump submodules/falcosecurity-rules from b4437c4 to 4d51b18 [#3607] - @dependabot[bot] update(docs): cherry pick CHANGELOG. [#3600] - @FedeDP update(cmake): update libs and driver to latest master [#3592] - @github-actions[bot] update(docs): bumped changelog for release 0.41.0, master sync [#3586] - @FedeDP chore(deps): Bump submodules/falcosecurity-rules from cb17833 to b4437c4 [#3578] - @dependabot[bot] Statistics MERGED PRS NUMBER Not user-facing 29 Release note 23 Total 52 Release Manager @ekoops \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.42.0-rc4\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.42.0-rc4\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.42.0-rc3\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.42.0-rc3\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.42.0-rc2\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.42.0-rc2\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.42.0-rc1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.42.0-rc1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.41.3\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.41.3\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.21.0\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.21.0-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 tgz-static-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.41.3 docker pull public.ecr.aws/falcosecurity/falco:0.41.3 docker pull docker.io/falcosecurity/falco-driver-loader:0.41.3 docker pull docker.io/falcosecurity/falco-driver-loader:0.41.3-buster docker pull docker.io/falcosecurity/falco:0.41.3-debian v0.41.3 Minor Changes update: bump container plugin to v0.3.1 [#3629] - @FedeDP Statistics MERGED PRS NUMBER Not user-facing 0 Release note 1 Total 1 Release Manager @leogr @ekoops \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.41.2\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.41.2\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.21.0\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.21.0-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 tgz-static-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.41.2 docker pull public.ecr.aws/falcosecurity/falco:0.41.2 docker pull docker.io/falcosecurity/falco-driver-loader:0.41.2 docker pull docker.io/falcosecurity/falco-driver-loader:0.41.2-buster docker pull docker.io/falcosecurity/falco:0.41.2-debian v0.41.2 Released on 2025-06-17\nStatistics MERGED PRS NUMBER Not user-facing 0 Release note 0 Total 0 Release Manager @leogr @ekoops \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.41.1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.41.1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.21.0\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.21.0-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 tgz-static-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.41.1 docker pull public.ecr.aws/falcosecurity/falco:0.41.1 docker pull docker.io/falcosecurity/falco-driver-loader:0.41.1 docker pull docker.io/falcosecurity/falco-driver-loader:0.41.1-buster docker pull docker.io/falcosecurity/falco:0.41.1-debian v0.41.1 Released on 2025-06-05\nBug Fixes fix(userspace/falco): when collecting metrics for stats_writer, create a libs_metrics_collector for each source [#3585] - @FedeDP fix(userspace/falco): only enable prometheus metrics once all inspectors have been opened [#3588] - @FedeDP Statistics MERGED PRS NUMBER Not user-facing 0 Release note 2 Total 2 Release Manager @FedeDP \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.41.1-rc1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.41.1-rc1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.41.0\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.41.0\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.21.0\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.21.0-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 tgz-static-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.41.0 docker pull public.ecr.aws/falcosecurity/falco:0.41.0 docker pull docker.io/falcosecurity/falco-driver-loader:0.41.0 docker pull docker.io/falcosecurity/falco-driver-loader:0.41.0-buster docker pull docker.io/falcosecurity/falco:0.41.0-debian v0.41.0 Released on 2025-05-29\nBreaking Changes :warning: cleanup(engine)!: only consider .yaml/.yml rule files [#3551] - @LucaGuerra cleanup(userspace)!: deprecate print of container.info [#3543] - @FedeDP cleanup(userspace/falco)!: drop deprecated in 0.40.0 CLI flags. [#3496] - @FedeDP Major Changes new(falco): add json_include_output_fields option [#3527] - @LucaGuerra new(build,userspace): switch to use container plugin [#3482] - @FedeDP new(docker,scripts,ci): use an override config file to enable ISO 8601 output timeformat on docker images [#3488] - @FedeDP Minor Changes chore(build): update falcoctl to v0.11.2, rules for artifact follow to v4 [#3580] - @LucaGuerra update(cmake): bumped falcoctl to 0.11.1 and rules to 4.0.0. [#3577] - @FedeDP update(containers): update opencontainers labels [#3575] - @LucaGuerra update(metrics): improve restart/hot_reload conditions inspection [#3562] - @incertum update: empty values in exceptions won't emit a warning anymore [#3529] - @leogr chore(falco.yaml): enable libs_logger by default with info level [#3507] - @FedeDP Bug Fixes fix(metrics/prometheus): gracefully handle multiple event sources, avoid erroneous duplicate metrics [#3563] - @incertum fix(ci): properly install rpm systemd-rpm-macro package on building packages pipeline [#3521] - @FedeDP fix(userspace/falco): init cmdline options after loading all config files [#3493] - @FedeDP fix(cmake): add support for 16K kernel page to jemalloc [#3490] - @Darkness4 fix(userspace/falco): fix jemalloc enabled in minimal build. [#3478] - @FedeDP Non user-facing changes chore(deps): Bump submodules/falcosecurity-rules from 4ccf111 to cb17833 [#3572] - @dependabot[bot] update(cmake/rules): bump to falco-rules-4.0.0-rc1 [#3567] - @leogr cleanup(userspace/falco): drop unused libs_metrics_collector variable. [#3566] - @FedeDP update(cmake): update libs and driver to latest master [#3564] - @github-actions[bot] fix(build): fixed container custom_target sed command. [#3556] - @FedeDP chore(deps): Bump submodules/falcosecurity-rules from ae6ed41 to 4ccf111 [#3555] - @dependabot[bot] fix(cmake): fix bundled c-ares cmake issue with e.g. SLES [#3559] - @terror96 chore(deps): Bump submodules/falcosecurity-rules from 1d2c6b1 to ae6ed41 [#3553] - @dependabot[bot] chore: revert \u0026quot;chore(deps): Bump submodules/falcosecurity-rules from 1d2c6b1 to 371e431\u0026quot; [#3552] - @FedeDP update(cmake): update libs and driver to latest master [#3550] - @github-actions[bot] update(cmake): update libs and driver to latest master [#3549] - @github-actions[bot] update(adopters): added SafeDep as adopter [#3548] - @KunalSin9h update(cmake): update libs and driver to latest master [#3547] - @github-actions[bot] update(cmake): update libs and driver to latest master [#3541] - @github-actions[bot] fix(userspace): fixed engine openssl dep. [#3535] - @FedeDP fix(userspace/falco): fix outputs_http timeout [#3523] - @benierc fix(ci): use clang-19 to build modern_ebpf skeleton. [#3537] - @FedeDP update(cmake): update libs and driver to latest master [#3531] - @github-actions[bot] update(cmake): update libs and driver to latest master [#3530] - @github-actions[bot] update(cmake): update libs and driver to latest master [#3525] - @github-actions[bot] update(cmake): update libs and driver to latest master [#3520] - @github-actions[bot] update(cmake): update libs and driver to latest master [#3516] - @github-actions[bot] docs(README.md): cleanups and enhancements [#3514] - @leogr update(cmake): update libs and driver to latest master [#3511] - @github-actions[bot] chore(deps): Bump submodules/falcosecurity-rules from 1d2c6b1 to 371e431 [#3510] - @dependabot[bot] update(cmake): update libs and driver to latest master [#3508] - @github-actions[bot] update(cmake): update libs and driver to latest master [#3506] - @github-actions[bot] fix(userspace/falco): when counting -M timeout, do not account for async events [#3505] - @FedeDP chore(deps): Bump submodules/falcosecurity-rules from d8415c1 to 1d2c6b1 [#3504] - @dependabot[bot] docs(proposals): correct typo in example [#3499] - @leogr fix(docker): fixed entrypoints paths with new docker context. [#3492] - @FedeDP feat(falco/app): move actions not using config before load_config [#3483] - @ekoops refactor(falco/app): apply early return pattern in actions code [#3484] - @ekoops chore(deps): Bump submodules/falcosecurity-rules from abf6637 to d8415c1 [#3489] - @dependabot[bot] Add NETWAYS Web Services to ADOPTERS.md [#3487] - @mocdaniel chore: add back Falco static package to the release template. [#3472] - @FedeDP Statistics MERGED PRS NUMBER Not user-facing 36 Release note 17 Total 53 Release Manager @FedeDP \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.41.0-rc2\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.41.0-rc2\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.41.0-rc1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.41.0-rc1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.40.0\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.40.0\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.20.0\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.20.0-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 tgz-static-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.40.0 docker pull public.ecr.aws/falcosecurity/falco:0.40.0 docker pull docker.io/falcosecurity/falco-driver-loader:0.40.0 docker pull docker.io/falcosecurity/falco-driver-loader:0.40.0-buster docker pull docker.io/falcosecurity/falco:0.40.0-debian v0.40.0 Released on 2025-01-28\nBreaking Changes :warning: cleanup(userspac/falco)!: drop deprecated options. [#3361] - @FedeDP Major Changes new(docker): streamline docker images [#3273] - @FedeDP new(build): reintroduce static build [#3428] - @LucaGuerra new(cmake,ci): added support for using jemalloc allocator instead of glibc one and use it by default for release artifacts [#3406] - @FedeDP new(userspace,cmake): honor new plugins exposed suggested output formats [#3388] - @FedeDP new(userspace/falco): allow entirely disabling plugin hostinfo support. [#3412] - @FedeDP new(ci): use zig compiler instead of relying on centos7. [#3307] - @FedeDP new(falco): add buffer_format_base64 option, deprecate -b [#3358] - @LucaGuerra new(falco): add base_syscalls.all option to falco.yaml, deprecate -A [#3352] - @LucaGuerra new(falco): add falco_libs.snaplen option, deprecate -S / --snaplen [#3362] - @LucaGuerra Minor Changes update(cmake): bump falcoctl to v0.11.0 [#3467] - @alacuku chore(ci): add attestation for falco [#3216] - @cpanato chore(ci): build Falco in RelWithDebInfo, and upload Falco debug symbols as github artifacts [#3452] - @FedeDP update(build): DEB and RPM package requirements for dkms and kernel-devel are now suggestions [#3450] - @jthiltges Bug Fixes fix(userspace/falco): fix container_engines.cri.sockets not loading from config file [#3453] - @zayaanmoez fix(docker): /usr/src/'*' no longer created if $HOST_PATH/usr/src didn't exist at startup [#3434] - @shane-lawrence fix(docker): add brotli to the Falco image [#3399] - @LucaGuerra fix(userspace/engine): explicitly disallow appending/modifying a rule with different sources [#3383] - @mstemm Non user-facing changes chore(falco.yaml): remove comments about cri cli arguments [#3458] - @alacuku fix(ci): fixed reusable_build/publish_docker workflows. [#3459] - @FedeDP update(cmake): update libs and driver to latest master [#3455] - @github-actions[bot] chore(ci): bumped actions/upload-download-artifact. [#3454] - @FedeDP chore(docker): drop unused libelf dep from container images [#3451] - @leogr chore(docs): update plugins_hostinfo config file comment. [#3449] - @FedeDP new(build): add RelWithDebInfo target [#3440] - @shane-lawrence chore(deps): Bump submodules/falcosecurity-rules from 283a62f to abf6637 [#3448] - @dependabot[bot] update(ci): use 4cpu-16gb arm runners [#3447] - @LucaGuerra update(cmake): update libs and driver to latest master [#3439] - @github-actions[bot] chore: avoid deprecated funcs to calculate sha256 [#3442] - @federico-sysdig chore(ci): enable jemalloc in musl build. [#3436] - @FedeDP docs(falco.yaml): correct buffered_outputs description [#3427] - @leogr fix(userspace/falco): use correct filtercheck_field_info. [#3426] - @FedeDP update(cmake): update libs and driver to latest master [#3421] - @github-actions[bot] fix: update the url for the docs about the concurrent queue classes [#3415] - @Issif update(changelog): updated changelog for 0.39.2. [#3410] - @FedeDP update(cmake): update libs and driver to latest master [#3392] - @github-actions[bot] fix(cmake,docker): avoid cpp-httplib requiring brotli. [#3400] - @FedeDP chore(deps): Bump submodules/falcosecurity-rules from 407e997 to 283a62f [#3391] - @dependabot[bot] update(cmake): bump libs to latest master. [#3389] - @FedeDP update(cmake): update libs and driver to latest master [#3385] - @github-actions[bot] Make enable()/disable() virtual so they can be overridden [#3375] - @mstemm fix(ci): fixed shasum computation for bump-libs CI. [#3379] - @FedeDP chore(ci): use redhat advised method to check rpmsign success. [#3376] - @FedeDP chore(deps): Bump submodules/falcosecurity-rules from e38fb3f to 407e997 [#3374] - @dependabot[bot] Compile output clone [#3364] - @mstemm fix(ci): fixed bump-libs workflow syntax. [#3369] - @FedeDP new(ci): add a workflow to automatically bump libs on each monday. [#3360] - @FedeDP chore(deps): Bump submodules/falcosecurity-rules from b6ad373 to e38fb3f [#3365] - @dependabot[bot] cleanup(falco): reformat options::define [#3356] - @LucaGuerra Statistics MERGED PRS NUMBER Not user-facing 31 Release note 18 Total 49 Release Manager @FedeDP \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.40.0-rc1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.40.0-rc1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.39.2\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.39.2\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.18.2\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.18.2-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.39.2 docker pull public.ecr.aws/falcosecurity/falco:0.39.2 docker pull docker.io/falcosecurity/falco-driver-loader:0.39.2 docker pull docker.io/falcosecurity/falco-driver-loader-legacy:0.39.2 docker pull docker.io/falcosecurity/falco-no-driver:0.39.2 docker pull docker.io/falcosecurity/falco-distroless:0.39.2 v0.39.2 Released on 2024-11-21\nMinor Changes update(cmake): bumped falcoctl to v0.10.1. [#3408] - @FedeDP update(cmake): bump yaml-cpp to latest master. [#3394] - @FedeDP Non user-facing changes update(ci): use arm64 CNCF runners for GH actions [#3386] - @LucaGuerra Statistics MERGED PRS NUMBER Not user-facing 1 Release note 2 Total 3 Release Manager @FedeDP \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.39.1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.39.1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.18.1\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.18.1-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.39.1 docker pull public.ecr.aws/falcosecurity/falco:0.39.1 docker pull docker.io/falcosecurity/falco-driver-loader:0.39.1 docker pull docker.io/falcosecurity/falco-driver-loader-legacy:0.39.1 docker pull docker.io/falcosecurity/falco-no-driver:0.39.1 docker pull docker.io/falcosecurity/falco-distroless:0.39.1 v0.39.1 Released on 2024-10-09\nBug Fixes fix(engine): allow null init_config for plugin info [#3372] - @LucaGuerra fix(engine): fix parsing issues in -o key={object} when the object definition contains a comma [#3363] - @LucaGuerra fix(userspace/falco): fix event set selection for plugin with parsing capability [#3368] - @FedeDP Non user-facing changes update(changelog): updated changelog for 0.39.1. [#3373] - @FedeDP Statistics MERGED PRS NUMBER Not user-facing 1 Release note 3 Total 4 Release Manager @FedeDP \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.39.1-rc1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.39.1-rc1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.39.0\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.39.0\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.18.1\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.18.1-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.39.0 docker pull public.ecr.aws/falcosecurity/falco:0.39.0 docker pull docker.io/falcosecurity/falco-driver-loader:0.39.0 docker pull docker.io/falcosecurity/falco-driver-loader-legacy:0.39.0 docker pull docker.io/falcosecurity/falco-no-driver:0.39.0 docker pull docker.io/falcosecurity/falco-distroless:0.39.0 v0.39.0 Released on 2024-10-01\nBreaking Changes :warning: fix(falco_metrics)!: split tags label into multiple tag_-prefixed labels [#3337] - @ekoops fix(falco_metrics)!: use full name for configs and rules files [#3337] - @ekoops update(falco_metrics)!: rearrange n_evts_cpu and n_drops_cpu Prometheus metrics to follow best practices [#3319] - @incertum cleanup(userspace/falco)!: drop deprecated -t,-T,-D options. [#3311] - @FedeDP Major Changes feat(stats): add host_netinfo networking information stats family [#3344] - @ekoops new(falco): add json_include_message_property to have a message field without date and priority [#3314] - @LucaGuerra new(userspace/falco,userspace/engine): rule json schema validation [#3313] - @FedeDP new(falco): introduce append_output configuration [#3308] - @LucaGuerra new(userspace/falco): added --config-schema action to print config schema [#3312] - @FedeDP new(falco): enable CLI options with -o key={object} [#3310] - @LucaGuerra new(config): add container_engines config to falco.yaml [#3266] - @incertum new(metrics): add host_ifinfo metric [#3253] - @incertum new(userspace,unit_tests): validate configs against schema [#3302] - @FedeDP Minor Changes update(falco): upgrade libs to 0.18.1 [#3349] - @LucaGuerra update(systemd): users can refer to systemd falco services with a constistent unique alias falco.service [#3332] - @ekoops update(cmake): bump libs to 0.18.0 and driver to 7.3.0+driver. [#3330] - @FedeDP chore(userspace/falco): deprecate cri related CLI options. [#3329] - @FedeDP update(cmake): bumped falcoctl to v0.10.0 and rules to 3.2.0 [#3327] - @FedeDP update(falco_metrics): change prometheus rules metric naming [#3324] - @incertum Bug Fixes fix(falco): allow disable_cri_async from both CLI and config [#3353] - @LucaGuerra fix(engine): sync outputs before printing stats at shutdown [#3338] - @LucaGuerra fix(falco): allow plugin init_config map in json schema [#3335] - @LucaGuerra fix(userspace/falco): properly account for plugin with CAP_PARSING when computing interesting sc set [#3334] - @FedeDP Non user-facing changes feat(cmake): add conditional builds for falcoctl and rules paths [#3305] - @tembleking cleanup(falco): ignore lint commit [#3354] - @LucaGuerra chore(falco): apply code formatting [#3350] - @poiana chore: ignore_some_files for clang format [#3351] - @Andreagit97 sync: release 0.39.x [#3340] - @FedeDP fix(userspace/engine): improve rule json schema to account for source and required_plugin_versions [#3328] - @FedeDP cleanup(falco): use header file for json schema [#3325] - @LucaGuerra update(engine): modify append_output format [#3322] - @LucaGuerra chore: scaffolding for enabling code formatting [#3321] - @Andreagit97 update(cmake): bump libs and driver to 0.18.0-rc1. [#3320] - @FedeDP fix(ci): restore master and release CI workflow permissions. [#3317] - @FedeDP fixed the token-permission and pinned-dependencies issue [#3299] - @harshitasao update(cmake): bump falcoctl to v0.10.0-rc1 [#3316] - @alacuku ci(insecure-api): update semgrep docker image [#3315] - @francesco-furlan Add demo environment instructions and docker-config files [#3295] - @bbl232 chore(deps): Bump submodules/falcosecurity-rules from baecf18 to b6ad373 [#3301] - @dependabot[bot] update(cmake): bump libs and driver to latest master [#3283] - @jasondellaluce chore(deps): Bump submodules/falcosecurity-rules from 342b20d to baecf18 [#3298] - @dependabot[bot] chore(deps): Bump submodules/falcosecurity-rules from 068f0f2 to 342b20d [#3288] - @dependabot[bot] vote: add sgaist to OWNERS [#3264] - @sgaist Add Tulip Retail to adopters list [#3291] - @bbl232 chore(deps): Bump submodules/falcosecurity-rules from 28b98b6 to 068f0f2 [#3282] - @dependabot[bot] chore(deps): Bump submodules/falcosecurity-rules from c0a9bf1 to 28b98b6 [#3267] - @dependabot[bot] Added the OpenSSF Scorecard Badge [#3250] - @harshitasao chore(deps): Bump submodules/falcosecurity-rules from ea57e78 to c0a9bf1 [#3247] - @dependabot[bot] update(cmake,userspace): bump libs and driver to latest master. [#3263] - @FedeDP If rule compilation fails, return immediately [#3260] - @mstemm new(userspace/engine): generalize indexable ruleset [#3251] - @mstemm update(cmake): bump libs to master. [#3249] - @FedeDP chore(deps): Bump submodules/falcosecurity-rules from df963b6 to ea57e78 [#3240] - @dependabot[bot] chore(ci): enable dummy tests on the testing framework. [#3233] - @FedeDP chore(deps): Bump submodules/falcosecurity-rules from 679a50a to df963b6 [#3231] - @dependabot[bot] update(cmake): bump libs and driver to master. [#3225] - @FedeDP chore(deps): Bump submodules/falcosecurity-rules from 9e56293 to 679a50a [#3222] - @dependabot[bot] update(docs): update CHANGELOG for 0.38.0 (master branch) [#3224] - @LucaGuerra Statistics MERGED PRS NUMBER Not user-facing 35 Release note 22 Total 57 Release Manager @FedeDP \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.39.0-rc3\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.39.0-rc3\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.39.0-rc2\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.39.0-rc2\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.39.0-rc1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.39.0-rc1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.38.2\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.38.2\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.17.3\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.17.3-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.38.2 docker pull public.ecr.aws/falcosecurity/falco:0.38.2 docker pull docker.io/falcosecurity/falco-driver-loader:0.38.2 docker pull docker.io/falcosecurity/falco-driver-loader-legacy:0.38.2 docker pull docker.io/falcosecurity/falco-no-driver:0.38.2 docker pull docker.io/falcosecurity/falco-distroless:0.38.2 v0.38.2 Released on 2024-08-19\nBug Fixes fix(engine): fix metrics names to better adhere to best practices [#3272] - @incertum fix(ci): use vault.centos.org for centos:7 CI build. [#3274] - @FedeDP Statistics MERGED PRS NUMBER Not user-facing 0 Release note 2 Total 2 Release Manager @LucaGuerra \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.38.2-rc2\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.38.2-rc2\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.38.2-rc1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.38.2-rc1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.38.1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.38.1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.17.2\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.17.2-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.38.1 docker pull public.ecr.aws/falcosecurity/falco:0.38.1 docker pull docker.io/falcosecurity/falco-driver-loader:0.38.1 docker pull docker.io/falcosecurity/falco-driver-loader-legacy:0.38.1 docker pull docker.io/falcosecurity/falco-no-driver:0.38.1 docker pull docker.io/falcosecurity/falco-distroless:0.38.1 v0.38.1 Released on 2024-06-19\nMajor Changes new(metrics): enable plugins metrics [#3228] - @mrgian Minor Changes cleanup(falco): clarify that --print variants only affect syscalls [#3238] - @LucaGuerra update(engine): enable -p option for all sources, -pk, -pc etc only for syscall sources [#3239] - @LucaGuerra Bug Fixes fix(engine): enable output substitution only for syscall rules, prevent engine from exiting with validation errors when a plugin is loaded and -pc/pk is specified [#3236] - @mrgian fix(metrics): allow each metric output channel to be selected independently [#3232] - @incertum fix(userspace/falco): fixed falco_metrics::to_text implementation when running with plugins [#3230] - @FedeDP Statistics MERGED PRS NUMBER Not user-facing 0 Release note 6 Total 6 Release Manager @FedeDP \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.38.1-rc1\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.38.1-rc1\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;hr /\u0026gt; \u0026lt;div class=\u0026quot;changelog-item\u0026quot;\u0026gt; \u0026lt;h2 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Version \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/falco/tree/0.38.0\u0026quot; target=\u0026quot;_blank\u0026quot;\u0026gt;0.38.0\u0026lt;/a\u0026gt;\u0026lt;/h2\u0026gt; \u0026lt;div class=\u0026quot;changelog-item-content content\u0026quot;\u0026gt; \u0026lt;h3 class=\u0026quot;title is-size-3 is-size-4-mobile\u0026quot;\u0026gt;Download\u0026lt;/h3\u0026gt; \u0026lt;p\u0026gt;\u0026lt;a href=\u0026quot;https://github.com/falcosecurity/libs/releases/tag/0.17.1\u0026quot;\u0026gt;\u0026lt;img src=\u0026quot;https://img.shields.io/badge/LIBS-0.17.1-yellow\u0026quot; alt=\u0026quot;LIBS\u0026quot; loading=\u0026quot;lazy\u0026quot; /\u0026gt; Packages Download rpm-x86_64 deb-x86_64 tgz-x86_64 rpm-aarch64 deb-aarch64 tgz-aarch64 Images docker pull docker.io/falcosecurity/falco:0.38.0 docker pull public.ecr.aws/falcosecurity/falco:0.38.0 docker pull docker.io/falcosecurity/falco-driver-loader:0.38.0 docker pull docker.io/falcosecurity/falco-driver-loader-legacy:0.38.0 docker pull docker.io/falcosecurity/falco-no-driver:0.38.0 docker pull docker.io/falcosecurity/falco-distroless:0.38.0 v0.38.0 Released on 2024-05-30\nBreaking Changes :warning: new(scripts,docker)!: enable automatic driver selection logic in packages and docker images. Modern eBPF is now also the default driver and the highest priority one in the new driver selection logic. [#3154] - @FedeDP cleanup(falco.yaml)!: remove some deprecated configs [#3087] - @Andreagit97 cleanup(docker)!: remove unused builder dockerfile [#3088] - @Andreagit97 Major Changes new(webserver): a metrics endpoint has been added providing prometheus metrics. It can be optionally enabled using the new metrics.prometheus_enabled configuration option. It will only be activated if the metrics.enabled is true as well. [#3140] - @sgaist new(metrics): add rules_counters_enabled option [#3192] - @incertum new(build): provide signatures for .tar.gz packages [#3201] - @LucaGuerra new(engine): add print_enabled_rules_falco_logger when log_level debug [#3189] - @incertum new(falco): allow selecting which rules to load from the configuration file or command line [#3178] - @LucaGuerra new(metrics): add file sha256sum metrics for loaded config and rules files [#3187] - @incertum new(engine): throw an error when an invalid macro/list name is used [#3116] - @mrgian new(engine): raise warning instead of error on invalid macro/list name [#3167] - @mrgian new(userspace): support split config files [#3024] - @FedeDP new(engine): enforce unique exceptions names [#3134] - @mrgian new(engine): add warning when appending an exception with no values [#3133] - @mrgian feat(metrics): coherent metrics stats model including few metrics naming changes [#3129] - @incertum new(config): add falco_libs.thread_table_size [#3071] - @incertum new(proposals): introduce on host anomaly detection framework [#2655] - @incertum Minor Changes update(cmake): bump falcoctl to v0.8.0. [#3219] - @FedeDP update(rules): update falco-rules to 3.1.0 [#3217] - @LucaGuerra refactor(userspace): move falco logger under falco engine [#3208] - @jasondellaluce chore(docs): apply features adoption and deprecation proposal to config file keys [#3206] - @FedeDP cleanup(metrics): add original rule name as label [#3205] - @incertum update(falco): deprecate options -T, -t and -D [#3193] - @LucaGuerra refactor: bump libs and driver, support field modifiers [#3186] - @jasondellaluce chore(userspace/falco): deprecated old 'rules_file' config key [#3162] - @FedeDP chore(falco): update falco libs and driver to master (Apr 8th 2024) [#3158] - @LucaGuerra update(build): update libs to 026ffe1d8f1b25c6ccdc09afa2c02afdd3e3f672 [#3151] - @LucaGuerra cleanup: minor adjustments to readme, add new testing section [#3072] - @incertum refactor(userspace/engine): reduce allocations during rules loading [#3065] - @jasondellaluce update(CI): publish wasm package as dev-wasm [#3017] - @Rohith-Raju Bug Fixes fix(userspace/falco): fix state initialization avoid a crash during hot reload [#3190] - @FedeDP fix(userspace/engine): make sure exception fields are not optional in replace mode [#3108] - @jasondellaluce fix(docker): added zstd to driver loader images [#3203] - @FedeDP fix(engine): raise warning instead of error on not-unique exceptions names [#3159] - @mrgian fix(engine): apply output substitutions for all sources [#3135] - @mrgian fix(userspace/configuration): make sure that folders that would trigger permission denied are not traversed [#3127] - @sgaist fix(engine): logical issue in exceptions condition [#3115] - @mrgian fix(cmake): properly let falcoctl cmake module create /usr/share/falco/plugins/ folder. [#3105] - @FedeDP Non user-facing changes update(scripts/falcoctl): bump falco-rules version to 3 [#3128] - @alacuku build(deps): Bump submodules/falcosecurity-rules from 59bf03b to 9e56293 [#3212] - @dependabot[bot] chore(gha): update cosign to v3.5.0 [#3209] - @LucaGuerra build(deps): Bump submodules/falcosecurity-rules from 29c41c4 to 59bf03b [#3207] - @dependabot[bot] update(cmake): bumped libs to 0.17.0-rc1 and falcoctl to v0.8.0-rc6. [#3204] - @FedeDP build(deps): Bump submodules/falcosecurity-rules from 3f668d0 to 3cac61c [#3044] - @dependabot[bot] build(deps): Bump submodules/falcosecurity-testing from ae3950a to 7abf76f [#3094] - @dependabot[bot] fix(ci): enforce bundled deps OFF in build-dev CI [#3118] - @FedeDP build(deps): Bump submodules/falcosecurity-rules from 88a40c8 to 869c9a7 [#3156] - @dependabot[bot] update(cmake): bumped falcoctl to v0.8.0-rc5. [#3199] - @FedeDP build(deps): Bump submodules/falcosecurity-rules from 4f153f5 to 29c41c4 [#3198] - @dependabot[bot] update(cmake): bump falcoctl to v0.8.0-rc4 [#3191] - @FedeDP refactor: smart pointer usage [#3184] - @federico-sysdig build(deps): Bump submodules/falcosecurity-rules from ec255e6 to 4f153f5 [#3182] - @dependabot[bot] update(cmake): bumped libs and driver to latest master. [#3177] - @FedeDP chore(cmake): enable modern bpf build by default. [#3180] - @FedeDP cleanup(docs): fix typo in license blocks [#3175] - @LucaGuerra chore(docker,scripts): set old eBPF probe as lowest priority driver. [#3173] - @FedeDP build(deps): Bump submodules/falcosecurity-rules from 869c9a7 to ec255e6 [#3170] - @dependabot[bot] update(app): close inspectors at teardown time [#3169] - @LucaGuerra fix(docker): fixed docker entrypoints for driver loading. [#3168] - @FedeDP fix(docker,scripts): do not load falcoctl driver loader when installing Falco deb package in docker images [#3166] - @FedeDP update(ci): build both release and debug versions [#3161] - @LucaGuerra chore(userspace/falco): watch all configs files. [#3160] - @FedeDP fix(ci): update scorecard-action to v2.3.1 [#3153] - @LucaGuerra cleanup(falco): consolidate falco::grpc::server in one class [#3150] - @LucaGuerra new(build): enable ASan and UBSan builds with options and in CI [#3147] - @LucaGuerra fix(userspace): variable / function shadowing [#3123] - @sgaist build(deps): Bump submodules/falcosecurity-rules from fbf0a4e to 88a40c8 [#3145] - @dependabot[bot] fix(cmake): fix USE_BUNDLED_DEPS=ON and BUILD_FALCO_UNIT_TESTS=ON [#3146] - @LucaGuerra Add --kernelversion and --kernelrelease options to falco driver loader entrypoint [#3143] - @Sryther build(deps): Bump submodules/falcosecurity-rules from 44addef to fbf0a4e [#3139] - @dependabot[bot] chore: bump to latest libs commit [#3137] - @Andreagit97 refactor: Use FetchContent for integrating three bundled libs [#3107] - @federico-sysdig build(deps): Bump submodules/falcosecurity-rules from dc7970d to 44addef [#3136] - @dependabot[bot] build(deps): Bump submodules/falcosecurity-rules from f88b991 to dc7970d [#3126] - @dependabot[bot] refactor(ci): Avoid using command make directly [#3101] - @federico-sysdig docs(proposal): 20231220-features-adoption-and-deprecation.md [#2986] - @leogr build(deps): Bump submodules/falcosecurity-rules from b499a1d to f88b991 [#3125] - @dependabot[bot] docs(README.md): Falco Graduates within the CNCF [#3124] - @leogr build(deps): Bump submodules/falcosecurity-rules from 497e011 to b499a1d [#3111] - @dependabot[bot] chore(ci): bumped codeql actions. [#3114] - @FedeDP Cleanup warnings and smart ptrs [#3112] - @federico-sysdig new(build): add options to use bundled dependencies [#3092] - @mrgian fix(ci): test-dev-packages-arm64 needs build-dev-packages-arm64. [#3110] - @FedeDP refactor: bump libs and driver, and adopt unique pointers wherever possible [#3109] - @jasondellaluce cleanup: falco_engine test fixture [#3099] - @federico-sysdig refactor: test AtomicSignalHandler.handle_once_wait_consistency [#3100] - @federico-sysdig Cleanup variable use [#3097] - @sgaist cleanup(submodules): dropped testing submodule. [#3098] - @FedeDP cleanup(ci): make use of falcosecurity/testing provided composite action [#3093] - @FedeDP Improve const correctness [#3083] - @sgaist Improve exception throwing [#3085] - @sgaist fix(ci): update sync in deb and rpm scripts with acl [#3062] - @LucaGuerra cleanup(tests): consolidate Falco engine and rule loader tests [#3066] - @LucaGuerra cleanup: falco_engine deps and include paths [#3090] - @federico-sysdig fix: Some compiler warnings [#3089] - @federico-sysdig build(deps): Bump submodules/falcosecurity-rules from 0f60976 to 497e011 [#3081] - @dependabot[bot] fix(c++): add missing explicit to single argument constructors [#3069] - @sgaist Improve class initialization [#3074] - @sgaist build(deps): Bump submodules/falcosecurity-rules from 6ed2036 to 0f60976 [#3078] - @dependabot[bot] build(deps): Bump submodules/falcosecurity-rules from 1053b2d to 6ed2036 [#3067] - @dependabot[bot] fix(c++): add missing overrides [#3064] - @sgaist new(build): prune deb-dev and rpm-dev directories [#3056] - @LucaGuerra refactor(userspace): align falco to gen-event class family deprecation [#3051] - @jasondellaluce build(deps): Bump submodules/falcosecurity-rules from 3cac61c to 1053b2d [#3047] - @dependabot[bot] fix: adopt new libsinsp logger [#3026] - @therealbobo refactor: cleanup libs relative include paths [#2936] - @therealbobo chore(ci): bumped rn2md to latest master. [#3046] - @FedeDP Support alternate rules loader [#3008] - @mstemm fix(ci): fixed release body driver version. [#3042] - @FedeDP build(deps): Bump submodules/falcosecurity-rules from c39d31a to 3f668d0 [#3039] - @dependabot[bot] Statistics MERGED PRS NUMBER Not user-facing 72 Release note 38 Total 110 Release Manager @LucaGuerra \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt;\u0026lt;/div\u0026gt; ","summary":"","tags":null,"title":"Changelog","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/changelog/"},{"category":"docs","content":"This website contains documentation for the current version of Falco\nas well as up to six previous versions.","summary":"","tags":null,"title":"Available Documentation Versions","url":"https://v0-43--falcosecurity.netlify.app/docs/supported-doc-versions/"},{"category":"docs","content":"The Falco maintainers team works daily to provide more features, robust security and stability and better user experience to all adopters.\nThe maintainer team frequently communicates and meets to decide the next important areas for the project. This page is updated to list the efforts that are currently ongoing.\nRoad to Falco 1.0.0 Falco is on track to release its 1.0.0 version. While \u0026quot;one point oh\u0026quot; is just a number, it is a signal from the community that the project has reached a certain degree of stability and maturity. Following the graduation within the CNCF, this is the next logical step. Below we are listing the main topics we wish to address for this milestone.\nFalco Engine Provide standardized features adoption and depreciation policies, to make sure users understand when features can be considered stable and when they are being removed Make flagship features even more robust Streamlining falco.yaml structure CLI args consolidation and standardization Advanced metrics support Rules Syntax Address current language inconsistencies arising from our commitment to backward compatibility Introduce new constructs to address the most common user requests Drivers Make the modern eBPF probe the default driver Distribution Packages consolidation (by following Linux distro best practices) Publish signatures for drivers and all packages Make the Falco default image a \u0026quot;no-driver\u0026quot;/\u0026quot;distroless\u0026quot; image Complete supply chain security best practices efforts Documentation Better documentation around our feature adoption and deprecation policies Improve troubleshooting guide Improved guide and messages about running Falco for the first time and upon kernel update Enhance guidance on operationalizing and responding to Falco alerts based on adopters' feedback Revamp and enhance documentation for non-Kubernetes use cases (i.e. Falco installed on a Linux host) Integrations Improve stability in the container runtime integration Provide deeper access from the Plugin Framework to the Falco stream of events to make Falco more modular and easier to extend ","summary":"","tags":null,"title":"The Falco Roadmap","url":"https://v0-43--falcosecurity.netlify.app/docs/roadmap/"},{"category":"docs","content":"Introduction This section explains how to use the fd.sip.name field and the related fd.{clr}ip.name fields in the default falco ruleset. For example:\n- list: https_miner_domains items: [ \u0026#34;ca.minexmr.com\u0026#34;, \u0026#34;cn.stratum.slushpool.com\u0026#34;, \u0026#34;de.minexmr.com\u0026#34;, \u0026#34;fr.minexmr.com\u0026#34;, \u0026#34;mine.moneropool.com\u0026#34;, \u0026#34;mine.xmrpool.net\u0026#34;, \u0026#34;pool.minexmr.com\u0026#34;, \u0026#34;sg.minexmr.com\u0026#34;, \u0026#34;stratum-eth.antpool.com\u0026#34;, \u0026#34;stratum-ltc.antpool.com\u0026#34;, \u0026#34;stratum-zec.antpool.com\u0026#34;, \u0026#34;stratum.antpool.com\u0026#34;, \u0026#34;xmr.crypto-pool.fr\u0026#34; ] ## Add rule based on crypto mining IOCs - macro: minerpool_https condition: (fd.sport=\u0026#34;443\u0026#34; and fd.sip.name in (https_miner_domains)) The fd.sip.name field and the related fd.{clr}ip.name fields behave differently than the other fields in the falco ruleset. See the following to learn more.\nResolve Domains First, Match IPs Later When a rule contains a field fd.*ip.name, the domain names on the right hand side of the comparison (The foo.com in =foo.com or in (foo.com, bar.com)) are saved internally within the falco engine. The engine looks up the A records for those domains immediately and saves the set of returned IPs internally. This behavior prevents stalling the system call event loop to perform a blocking time-consuming DNS lookup at the time of the system call event.\nLater, when a system call event is matched against the condition in the filter, the actual IP address associated with the system call event (the server IP for fd.sip.name, the client IP for fd.cip.name, etc) is compared against the previously looked up set of IPs for the domain name. The actual IP is compared against the set of resolved IPs, based on the comparison operator (=/!=/in, perhaps with a preceding not, etc) and results in a true/false result.\nHere's an example. If a rule contains a predicate evt.type=connect and fd.sip.name=yahoo.com, the engine resolves the domain yahoo.com to a set of IPs (say 1.2.3.4, 1.2.3.5, 1.2.3.6) at the time the rules are loaded. Later, if a connect system call occurs (say to 1.2.3.5), the server side of the connection is compared against that set of IPs. Since the actual IP 1.2.3.5 is in the set of IPs for the domain yahoo.com, the rule snippet resolves to true.\nThe right hand side of a predicate can be in e.g. fd.sip.name in (yahoo.com, foo.com). In this case, the set of IPs for both domains are resolved and held. A later system call event will compare a given IP to the set of IPs for both sets of domains.\nHow Falco Engine Refreshes Domain/IP Mappings The actual lookup of domains is done on a separate thread, to avoid stalling the main system call event loop. Additionally, the set of IPs for the domain is refreshed periodically, with the following strategy:\nDomain names have a base refresh time of 10 seconds. If after a refresh cycle the IP addresses haven't changed, the refresh timeout for that domain name is doubled until 320 seconds (~5mins). Caveats Related to fd.*ip.name Fields There are a few caveats related to the use of fd.*ip.name fields that should be considered when writing Falco Rules.\nThe Right-Hand Side Must Be a Resolvable Domain Name Since the right hand side of the predicate (e.g. the foo.com part of fd.sip.name=foo.com) is used to perform a DNS lookup at the time the rules are loaded, it must be a resolvable domain name. As a result, it's not possible to use domain substrings in conjunction with comparison operators like startswith/endswith/contains/etc. e.g. fd.sip.name contains company.com. Also, the falco engine must be able to resolve domain names in order for rules using fd.*ip.name fields to return accurate results.\nUsing fd.*ip.name Fields in Outputs The fields fd.*ip.name can be used in rule outputs, but they will return meaningful values only when the actual IP for the system call event matches one of the IPs associated with the domain name for the field. For example, the following rule will display a meaningful output for ...IP=%fd.sip.name, as the rule condition has a positive comparison for a fd.sip.name field:\n- rule: Connect to Yahoo desc: Detect Connects to yahoo.com IPs condition: evt.type=connect and fd.sip.name=yahoo.com output: Some connect to yahoo | command=%proc.cmdline connection=%fd.name IP=%fd.sip.name priority: INFO In contrast, this rule will never display a meaningful output for ...IP=%fd.sip.name, as the comparison uses a negative match:\n- rule: Connect to Anything but Yahoo desc: Detect Connects to anything other than yahoo.com IPs condition: evt.type=connect and fd.sip.name!=yahoo.com output: Some connect to something other than yahoo | command=%proc.cmdline connection=%fd.name IP=%fd.sip.name priority: INFO The rule can match a given connect to an IP like 1.5.6.7, which is outside the known IPs 1.2.3.4/1.2.3.5/1.2.3.6 and generate an alert, but the value for %fd.sip.name will be blank. (The full connection information is still available in %fd.name, though.)\nLimited Comparison Operators Although the falco rules syntax supports a fairly wide set of comparison operators for IPs, including contains, the only allowed operators for fd.*ip.name fields are =/!=/in, with an optional preceding not.\n","summary":"","tags":null,"title":"Resolving Domain Names in Falco Rules","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/fd-sip-name/"},{"category":"docs","content":"You have learned how to write Falco rules with best practices in mind and are now ready to deploy Falco to production and operationalize the rules. You might be wondering, \u0026quot;How do I go about this? How can I not only get the most value out of Falco but also maintain the rules effectively across varying infrastructure setups?\u0026quot;\nThe Falco Project has introduced the Rules Maturity Framework to precisely assist you in this process. The framework facilitates the adoption of the stable default rules more effectively while also providing guidance for custom rules. This framework ensures a smooth transition for adopters, whether they use rules generically or for specific use cases. A smooth adoption process is defined by making it easy for adopters to understand each rule and also gain an understanding of not just what the rule is doing, but also how beneficial it can be under various circumstances. As a result, adopters should have a clear idea of which rules can likely be adopted as-is versus which rules may require significant engineering efforts to evaluate and adopt.\nTo begin, allocate some time to assess the top cyber threats that are specific to your organization and require monitoring in place. One way to go about this is by exploring the already mentioned default rules tagged with the maturity level \u0026quot;stable\u0026quot; first. Explore the source falco_rules.yaml file and/or the latest rules overview document. These rules are designed to detect more universal system-level cyber threats, aligned with the Mitre Attack framework. Examples include remote code execution, generic malicious executions, container escapes, network pivots, privilege escalations, or credentials lifting. Some of these rules are also valuable for compliance-related monitoring.\nDepending on your familiarity with security monitoring and detections, a little ramping up may be necessary to assess how useful a particular rule is in your environment. This includes determining the level of customization needed for a rule, for example, tuning out noise to reduce False Positives, and on the flip side, ensuring you are resilient against False Negatives. Additionally, it involves determining the appropriate output fields and the deployment configurations you need. It may also include finding the most optimal ways to maintain different deployment configurations across various infrastructures where you intend to deploy Falco. Existing descriptions of Falco rules, the official guides you've read, as well as the many blog posts hosted by The Falco Project, can provide you with further assistance.\nHigh-level Phases Newcomers to Falco will be encouraged to start by configuring their setup with introductory rules labeled as \u0026quot;Falco's default rules\u0026quot; (maturity_stable). These rules, which are currently based on syscall and container events, live in the established falco_rules.yaml file. As users become more familiar with Falco and better understand their unique environments, they can gradually fine-tune the default rules to meet their specific requirements. Tuning rules goes hand in hand with assessing the performance overhead and adjusting Falco's configuration accordingly. This consideration is important to keep in mind as there are usually limitations to the budget allocated for security monitoring. Once adopters have integrated the stable default rules with low false positives and acceptable performance consistently, they can add a next set of rules. This set may include rules with maturity_incubating or maturity_sandbox, offering more specific detections and/or broader monitoring, depending on the rule. The level of engineering effort needed to effectively use these rules at this stage is likely to increase. Alongside each of these phases, creating custom rules early on often makes a lot of sense. For instance, enabling monitoring around sensitive files that are unique to your environment and ecosystem would be an appropriate example. The same approach could be applied to set up monitoring for crown jewel services with detailed knowledge of their usual execution patterns, and then set up alerts for any deviations. Lastly, up until now, we focused on syscall and container event-based default rules. However, Falco also features a rich plugins system alongside plugin rules that you can explore to see if they are a fit for your ecosystem. Disclaimer: The maturity level of the rules, however, does not directly reflect their potential for generating noise in the adopters' environment. This is due to the unique and constantly changing nature of each environment, especially in cloud environments, making it challenging to accurately predict the impact of rules.\nEffective End-to-End Operationalization Effective end-to-end operationalization is ideally accomplished through 24/7 detection triage by security analysts and pre-defined runbooks in the incident response workflows. This aspect is unique to your environment, and you can explore how Falco alerts can be augmented with additional data enrichments. Finding the right scope of monitoring can be achieved through experimentation. We also encourage you to find ways to perform continuous end-to-end testing or simulations to ensure the entire data pipeline is functional. This includes validating that Falco is logging the events, ensuring subsequent log transport to your end destination (which can be a data lake and compute platform or a SIEM) is working, and having effective triage and response mechanisms in place.\nContinuous Learning and Maintenance Falco continuously evolves and improves over time. This also means that for each Falco release, allocating time to explore the newest features can be beneficial. Furthermore, infrastructure, cloud environments, and your organization's applications keep evolving as well. Therefore, Falco rules require constant tuning and maintenance to ensure the desired monitoring quality.\n","summary":"","tags":null,"title":"Adoption of Falco Rules in Production","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/adoption-rules/"},{"category":"docs","content":"Introduction This section explains how the fields fs.path.* work and when they can be used.\nMotivation A variety of different syscalls take file system paths as arguments. However, there is little consistency in the fields that can access those file system paths. Depending on the syscall, the file system path might be available in evt.rawarg.path, evt.rawarg.pathname, evt.rawarg.name, fd.name, etc. This makes writing simple Falco rules that act on file system paths challenging because the field must depend on the syscall.\nTo help address this inconsistency, in Falco version 0.36, we added a new set of fields that normalize file system paths across various syscalls.\nWhat Counts As A File System Path? Lots of existing fields also refer to file system paths. For example, proc.exepath contains the file system path for an executable, and there are related fields proc.pexepath/proc.aexepath. container.mount.* fields all contain the file system paths for file systems mounted into a container.\nThe fs.path.* fields are only populated for syscalls generally related to reading, writing, or modifying some file system object and have a file system path as an argument. The goal is to have a single set of fields that can always be relied on to refer to those paths, compared to checking the widely varying per-event fields.\nfs.path.* fields The following fields are available for any syscall that operates on a file system path:\nfs.path.name fs.path.nameraw fs.path.source fs.path.sourceraw fs.path.target fs.path.targetraw fs.path.name is for file operations that work on a path like open, unlink, rmdir, etc. For other file operations that have a source and target, like cp, symlink, link, mv, etc., there are fields fs.path.source and fs.path.target.\nThese convert relative paths to absolute paths when needed, using the thread's current working directory (cwd).\nfs.path.nameraw/fs.path.sourceraw/fs.path.targetraw are like the above but do not convert relative paths to absolute paths. They always contain the original path, which may or may not be relative.\nThe fields only work for exit events and only return a value if the syscall succeeds.\nThe below tables show:\nthe specific syscalls that are are supported the specific falco event identifiers are supported. The reason there are multiple event identifiers for the same syscall (e.g. MKDIR vs MKDIR_2) is that libs used to define new events every time we added/modified arguments to the event. Older applications using the older version of libs will use the older event identifier for the syscall name, while newer applications will use the newer event identifier. the specific event fields that are mapped to fs.path.* fields Single Argument File System Syscalls Syscall fs.path.name field mkdir evt.rawarg.path mkdirat evt.rawarg.path rmdir evt.rawarg.path unlink evt.rawarg.path unlinkat evt.rawarg.name open evt.rawarg.name openat evt.rawarg.name openat2 evt.rawarg.name fchmod fd.name fchmodat evt.rawarg.filename chmod evt.rawarg.filename chown evt.rawarg.path lchown evt.rawarg.path fchown fd.name fchownat evt.rawarg.pathname quotactl evt.rawarg.special umount evt.rawarg.name umount2 evt.rawarg.name Source/Target File System Syscalls Syscall fs.path.source field fs.path.target field rename evt.rawarg.oldpath evt.arg.newpath renameat evt.rawarg.oldpath evt.arg.newpath renameat2 evt.rawarg.oldpath evt.arg.newpath link evt.arg.newpath evt.rawarg.oldpath linkat evt.arg.newpath evt.rawarg.oldpath symlink evt.arg.linkpath evt.rawarg.target symlinkat evt.arg.linkpath evt.rawarg.target mount evt.rawarg.dev evt.rawarg.dir Example Rule Using fs.path.* Fields Here is an example rule that allows monitoring a wide variety of different file related operations below a set of specifed root directories:\n- list: file_operation_paths items: [/tmp/example-dir] macro: file_operation condition: (mkdir or rename or remove or open_write or create_symlink or evt.type in (link, linkat))\nrule: Any File Related Operation on Path desc: Detect any file operation on a single path condition: (fs.path.name pmatch (file_operation_paths) or fs.path.source pmatch (file_operation_paths) or fs.path.target pmatch (file_operation_paths)) and file_operation output: \u0026gt; Some File Related Operation on Path (evt.type=%evt.type path=%fs.path.name source=%fs.path.source target=%fs.path.target %user.name=%user.name proc.cmdline=%proc.cmdline proc.pcmdline=%proc.pcmdline container.id=%container.id container.name=%container.name image=%container.image.repository) priority: DEBUG source: syscall ","summary":"","tags":null,"title":"Accessing File System Paths in Falco Rules","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/fspath/"},{"category":"docs","content":"Falco and its ecosystem components are available as downloadable files and OCI (Open Container Initiative) artifacts. This page provides the official URLs for accessing these artifacts.\nFor a comprehensive overview of the available artifacts and their versioning, refer to the Falco release documentation.\nPackages For installation instructions, refer to the Install on a host (DEB, RPM) or the Install on a host (tarball) pages.\nThe tables below provide quick links for Falco packages hosted at download.falco.org.\nPackages Download for Linux x86_64 rpm deb binary Packages Download for Linux aarch64 rpm deb binary Container images For deployment instructions, refer to the Deploy as a container or the Deploy on Kubernetes pages.\nThe tables below provide quick pull commands for Falco container images hosted at Docker Hub.\ntag pull command description latest docker pull falcosecurity/falco:latest Distroless image with the latest released of Falco. No tools are included in the image. version docker pull falcosecurity/falco:\u0026lt;version\u0026gt; Distroless image with a specific version of Falco such as 0.43.0. No tools are included in the image. latest-debian docker pull falcosecurity/falco:latest-debian Debian-based image with the latest released of Falco. Available since Falco 0.40. version-debian docker pull falcosecurity/falco:\u0026lt;version\u0026gt;-debian Debian-based image with a specific version of Falco such as 0.43.0. Available since Falco 0.40. latest docker pull falcosecurity/falco-driver-loader:latest Debian-based image with the most recent Falco driver loader and the building toolchain. version docker pull falcosecurity/falco-driver-loader:\u0026lt;version\u0026gt; Debian-based image with specific version of falco-driver-loader such as 0.43.0 and the building toolchain. latest-buster docker pull falcosecurity/falco-driver-loader:latest Same as falco-driver-loader:latest but based on Debian buster. Available since Falco 0.40. version-buster docker pull falcosecurity/falco-driver-loader:\u0026lt;version\u0026gt; Same as falco-driver-loader:\u0026lt;version\u0026gt; but based on Debian buster. Available since Falco 0.40. Rules The Falco packages and container images come with a built-in ruleset file (including only rules with maturity stable level). Those rules and others with different maturity levels are available as downloadable files at download.falco.org and are also available as OCI artifacts (refer to falcoctl documentation for downloading and installing OCI artifacts).\nPlugins Plugins hosted by The Falco Project are available as downloadable packages at download.falco.org and are also available as OCI artifacts (refer to falcoctl documentation for downloading and installing OCI artifacts).\nDrivers When using Falco for Kernel Events (i.e., with the syscall data source enabled), the Falco binary relies on having a driver available on the host system.\nStarting from Falco 0.38.0, the default driver is the Modern eBPF driver, which is included in the Falco binary and built using the CO-RE \u0026quot;Compile Once - Run Everywhere\u0026quot; technology. If your system satisfies the modern eBPF driver requirements, no further action is needed. Otherwise, you need to use the Kernel Module, which provides wider compatibility.\nIn brief, you don't need to install a driver if you are either:\nusing the modern eBPF driver (default option) or if you are using only plugin data sources. Pre-built Falco drivers for a vast variety of Linux Kernel releases are distributed at download.falco.org.\nTo download a pre-built driver, navigate to the driver versions' directory that is compatible with the Falco binary you're currently using (check with falco --version), then download the kernel artifact corresponding to your kernel release (uname -r) for either .ko (kernel module) or .o (legacy eBPF driver, deprecated). To make this easier, Falco comes with the falcoctl tool that automates the driver download (or tries to build it on the fly). The Install guide will explain this more, and the text blob below also has more information.\nTools Falcoctl falcoctl is a command-line tool that helps you manage Falco and its ecosystem components. It is included in the Falco distribution and can be used to download and install Falco drivers, rules, plugins, and other artifacts.\nYou can also manually download falcoctl from GitHub releases.\nHelm Charts For deployment instructions using Helm, please refer to the Deploy on Kubernetes page.\nThe Falco Project provides various Helm charts and documentation for Falco and its ecosystem tools.\nFor detailed information about these charts, refer to the Falco Helm Charts repository.\nFor information about how to download and install Helm, see the official Helm installation guide.\nView Installing Helm Guide\n","summary":"","tags":null,"title":"Download","url":"https://v0-43--falcosecurity.netlify.app/docs/setup/download/"},{"category":"docs","content":"Learn more about Falco If you'd like to dive deeper into the various components that make up Falco, check out the following resources:\nUnderstand Falco's event sources Learn more about Falco Rules Review Falco Alerts Discover Falco Plugins Read the Falco Glossary ","summary":"","tags":null,"title":"Additional Resources","url":"https://v0-43--falcosecurity.netlify.app/docs/getting-started/falco-additional/"},{"category":"docs","content":" This style guide only applies to Falco 0.36 and above. Style Guide Before diving in, read the sections on Falco rules Basics and Condition Syntax. Also, check out existing Falco Rules for best practices in writing rules.\nIn addition, the resources under references/rules provide complementary information. We highly recommend regularly revisiting each guide to stay up-to-date with the latest advancements of Falco.\nA rule declaration is represented as a YAML object consisting of multiple keys. The suggested order for these keys is as follows:\n- rule: desc: condition: output: priority: tags: ... other keys if applicable in no particular order Naming Choose a concise title that summarizes the essence of the rule's purpose. Rule's name must start with an upper-case letter. For macro and list, use lowercase_separated_by_underscores, for example, kernel_module_load.\nDescription Aligning with Falco's Rules Maturity Framework, it is encouraged to not just include a longer description of what the rule detects but also to give advice on how to tune this rule and reduce possible noise. If applicable, elaborate on how to correlate the rule with other rules or data sources for incident response. However, keep them concise. The description should end with a period.\nCondition Syntax These recommendations prioritize performance impact while maintaining a consistent style for better understanding and easier customization. This approach ensures more manageable maintenance of the rules in the long run.\nWe explain the high-level principles using example rules or snippets.\nEach upstream Falco rule must include an evt.type filter; otherwise, you will get a warning. Rule no_evttype: warning (no-evttype): proc.name=foo did not contain any evt.type restriction, meaning that it will run for all event types. This has a significant performance penalty. Consider adding an evt.type restriction if possible. Prioritize the evt.type filter first; otherwise, you will get a warning. Falco buckets filters per evt.type for efficient rules matching through applying the rule's Abstract Syntax Tree (AST) to relevant event types only. A nice side effect is better readability as well. Rule evttype_not_equals: warning (trailing-evttype): evt.type!=execve does not have all evt.type restrictions at the beginning of the condition, or uses a negative match (i.e. \u0026#34;not\u0026#34;/\u0026#34;!=\u0026#34;) for some evt.type restriction. This has a performance penalty, as the rule can not be limited to specific event types. Consider moving all evt.type restrictions to the beginning of the rule and/or replacing negative matches with positive matches if possible. To maintain performance, avoid mixing unrelated event types in one rule. Typically, only variants should be mixed together, for example: evt.type in (open, openat, openat2).\nThe best practice and requirement for upstream rules are to only define positive evt.type expressions. Using evt.type!=open, for example, would monitor each of the Supported Syscalls, resulting in a significant performance penalty. For more information, read the Adaptive Syscalls Selection in Falco blog post.\nAfter the evt.type filter, place your positive expression filters to efficiently eliminate the most events step by step. An exception to this rule is the container macro, which can quickly eliminate many events. Therefore, the guiding principle of \u0026quot;divide and conquer\u0026quot; commonly used in database query recommendations, also applies to Falco's filter statements.\n- macro: open_write condition: (evt.type in (open,openat,openat2) and evt.is_open_write=true and fd.typechar=`f` and fd.num\u0026gt;=0) ... - macro: container condition: (container.id != host) ... - rule: Detect release_agent File Container Escapes ... condition: open_write and container and fd.name endswith release_agent and (user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and thread.cap_effective contains CAP_SYS_ADMIN ... Effective Falco rules should now already be in a good state. Additionally, use exclusionary statements mostly to filter out common anti-patterns and noise. Often, these statements are based on profiling. You will notice that many upstream rules provide an empty template macro for this purpose, which you can customize. - macro: spawned_process condition: (evt.type in (execve, execveat)) ... - list: known_drop_and_execute_containers items: [] - rule: Drop and execute new binary in container ... condition: spawned_process and container and proc.is_exe_upper_layer=true and not container.image.repository in (known_drop_and_execute_containers) ... Use existing macros for reusability purposes, if applicable (e.g. spawned_process macro). Exercise caution when dealing with complicated nested statements in Falco rules, and ensure you use parentheses consistently to achieve the desired correct behavior. Remember, using too many parentheses does not cause any harm. To avoid grammatical syntax errors or sub-optimal performance, refrain from combining or statements with negation. Instead, use or statements only for positive filters. - macro: minerpool_https condition: (fd.sport=\u0026#34;443\u0026#34; and fd.sip.name in (https_miner_domains)) ... condition: ... and ((minerpool_http) or (minerpool_https) or (minerpool_other)) Furthermore, it is preferred to use and not to consistently negate a positive sub-expression. Avoid double-negation. condition: ... and not fd.snet in (rfc_1918_addresses) For operations involving string comparison, startswith or endswith should be preferred over contains whenever possible, as they are more efficient. Whenever possible, try to avoid making a rule expression too long. Upstream rules shall not contain any exceptions to ensure simpler rules and facilitate better adoption. High-volume syscalls can increase CPU usage and cause kernel side event drops in production systems. When deploying Falco, consider trade-offs and experiments, particularly with I/O related syscalls, as it depends on your unique environment. The upstream rules do not include rules enabled by default regarding I/O syscalls. Output Fields Each rule must include output fields.\nFor the output fields, expect that each Falco release typically exposes new Supported Output Fields that can help you write more expressive rules and/or add more context to a rule for incident response.\nBuilding upon the guide around writing rules with respect to Falco Outputs, when considering upstreaming your rule, core output fields relevant for this rule must be included. At the same time, we try to keep them to a minimum, and adopters can add more output fields as they see fit.\nFor each rule include the critical fields listed below related to process and user information, as well as the actual event type. For example, the tty field (terminal) can help determine if the process ran in an interactive shell. Additionally, examining the exepath alongside the process name provides insights into whether the binary might be located in more suspicious folders like tmp. Understanding the direct parent process is vital for basic process lineage analysis.\nevt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty For rules involving only spawned_process, please also include %evt.arg.flags in the output fields. If a rule involves multiple syscalls beyond spawned_process, do not include %evt.arg.flags.\nexe_flags=%evt.arg.flags General tip: Refer to the Event Table Definitions for the evt.arg.* fields for each supported syscall, for which we extract and parse the arguments.\nFor network-related rules include:\nconnection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto For file-related rules include:\nfile=%fd.name ... and additional specialized fields from the raw args if applicable, such as newpath=%evt.arg.newpath for non-file descriptor events like symlinking or renaming. Alternatively, you can explore more recent fs.path.* variants to simplify the consistent logging of file or directory paths, even for non-file descriptor events. Previously, tapping into the raw args as described above was required for such events.\nSupported Output Fields container.* retrieved from the container runtime socket Supported Output Fields k8s.* also retrieved from the container runtime socket All of these fields are incredibly crucial for effective incident response and play a vital role in determining the workload owner.\nFor specialized use cases, generic fields such as %container.ip or %container.cni.json can be further helpful for incident response, especially concerning non-network syscall related alerts in Kubernetes. These fields can be correlated, for example, with network proxy logs. Additionally, for certain rules, it can be important to traverse the parent process lineage for up to 7 levels. In some cases, instead of relying solely on the process name, it might be more effective to traverse the exepath, for example, proc.aexepath[2]. The process name and executable of the session leader (%proc.sname, %proc.sid.*) and process group leader (%proc.vpgid.*), or other specific process fields such as proc.is_exe_upper_layer, proc.is_exe_from_memfd or proc.is_vpgid_leader, can also hold considerable generic value for each rule. However, it is up to you as an adopter to decide.\nWe kindly ask you to add fields related to IDs later in your customization process to keep the upstream Falco output fields to a minimum. This is because there are many ID-related fields, such as %proc.pid %proc.ppid %proc.vpid %proc.pvpid %proc.sid %proc.vpgid .... You can explore the -p option for this purpose and add these fields to each rules' output fields.\nFalco also supports outputting the output as a resolved string. Therefore, use a sentence style, first concisely re-iterating the rule's purpose, and then including the output field in parentheses after the = character, with its meaning explained before the = character, adhering to the snake_case variable naming convention.\noutput: \u0026#34;Read monitored file via directory traversal | file=%fd.name fileraw=%fd.nameraw gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty\u0026#34; Priority Please refer to the relevant reference/rules section and the Basic Rules Guide for more information.\nWhen considering upstreaming the rule to The Falco Project, the priority level shall not be set to DEBUG and instead shall be at a minimum of INFO.\nTags Tags include various categories to convey relevant information about the rule.\nAccording to the Falco Rules Maturity Framework, the first tag in the tags list must always indicate the maturity of the rule. The Rules Repo contains concrete guidance on how to categorize a rule when considering upstreaming the rule to The Falco Project.\nmaturity_stable maturity_incubating maturity_sandbox maturity_deprecated Next, the tags must indicate for what workloads this rule is relevant. Add host and container if the rule works for any event. You can include additional tags to specify the rule's type, such as process, network, k8s, aws, etc.\nWhen considering upstreaming your rule, we expect the Mitre Attack phase followed by the best Tactic or Technique, whichever is the best fit. This information is used to create the Rules Overview Document of Falco's predefined rules and also help the Falco adoption process.\nLastly, if the rule is relevant for a compliance use case, please add the corresponding PCI_DSS_* or NIST_* tag, referring to the Validating NIST Requirements with Falco and PCI/DSS Controls with Falco blog posts and rules contributing criteria outlined in the Rules Repo.\ntags: [maturity_incubating, host, container, filesystem, mitre_defense_evasion, NIST_800-53_AU-10] Additional Information Rule Types and Robustness Some rules are more specific signatures, while others focus on behavior-based detection. When testing rules, it's essential to consider not only if the rule catches the intended attack or how much noise it could generate but also its robustness. Robustness refers to how easily an attacker can bypass the detection by making minor changes to their payload or approach. Exploring different approaches to catch an attack can help identify the most effective detection method.\nRules Loading Refer to the up-to-date description in the falco.yaml file for rules_files to understand in which order rules are loaded. Keep in mind that Falco by default applies rules per event type on a \u0026quot;first match wins\u0026quot; basis. Starting from Falco Release 0.36.0, you have the option to modify the configuration to rule_matching: all. This change ensures that rules sharing the same event type cannot override each other, preventing inconsistent logging. Be aware, though, that this modification may lead to increased CPU usage.\nContributing Your Falco Rules Refer to the Contributing page and the How to Share Your Falco Rules guide.\n","summary":"","tags":null,"title":"Style Guide of Falco Rules","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/style-guide/"},{"category":"docs","content":" The gRPC Output as well as the embedded gRPC server have been deprecated in Falco 0.43.0 and will be removed in a future release. Until removal and since Falco 0.43.0, using any of them will result in a warning informing the user about the deprecation. Users are encouraged to leverage another output and/or Falcosidekick, as the usage will result in an error after the removal.\n// SPDX-License-Identifier: Apache-2.0 /* Copyright (C) 2023 The Falco Authors. Licensed under the Apache License, Version 2.0 (the \u0026#34;License\u0026#34;); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an \u0026#34;AS IS\u0026#34; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ syntax = \u0026#34;proto3\u0026#34;; package falco.version; option go_package = \u0026#34;github.com/falcosecurity/client-go/pkg/api/version\u0026#34;; // This service defines a RPC call // to request the Falco version. service service { rpc version(request) returns (response); } // The `request` message is an empty one. message request { } // The `response` message contains the version of Falco. // It provides the whole version as a string and also // its parts as per semver 2.0 specification (https://semver.org). message response { // falco version string version = 1; uint32 major = 2; uint32 minor = 3; uint32 patch = 4; string prerelease = 5; string build = 6; // falco engine version uint32 engine_minor = 7; string engine_fields_checksum = 8; uint32 engine_major = 9; uint32 engine_patch = 10; string engine_version = 11; }","summary":"","tags":null,"title":"Version","url":"https://v0-43--falcosecurity.netlify.app/docs/developer-guide/grpc/version/"},{"category":"docs","content":"GKE Google Kubernetes Engine (GKE) uses Container-Optimized OS (COS) as the default operating system for its worker node pools. COS is a security-enhanced operating system that limits access to certain parts of the underlying OS. Because of this security constraint, Falco cannot insert its Kernel Module to process events for system calls. However, COS provides the ability to leverage eBPF (extended Berkeley Packet Filter) to supply the stream of system calls to the Falco engine.\nTo use Falco on GKE, you need to deploy using the Modern eBPF. The Modern eBPF is the default driver for Falco 0.38.0 and later, so no further action is required in this case.\ngVisor The gVisor engine has been deprecated in Falco 0.43.0 and will be removed in a future release. Until removal and since Falco 0.43.0, using it will result in a warning informing the user about the deprecation. Users are encouraged to switch to another engine, such as the modern eBPF probe, as the usage will result in an error after the removal.\nFalco offers native support for gVisor. A specific configuration is necessary to integrate Falco with gVisor seamlessly. For detailed instructions, refer to the gVisor Event Source documentation.\n","summary":"","tags":null,"title":"Specific Environments","url":"https://v0-43--falcosecurity.netlify.app/docs/setup/enviroments/"},{"category":"docs","content":"minikube The easiest way to use Falco on Kubernetes in a local environment is on Minikube.\nWhen running minikube with one of the following drivers virtualbox, qemu, kvm2, it creates a VM that runs the various Kubernetes services and a container framework to run Pods, etc. Generally, it's not possible to build the Falco kernel module directly on the minikube VM, as the VM doesn't include the kernel headers for the running kernel.\nTo address this, starting with Falco 0.33.0 prebuilt kernel modules and bpf probes for the last 3 minikube major versions, including minor versions, are available at https://download.falco.org/?prefix=driver/. This allows the download fallback step to succeed with a loadable driver. New versions of minikube are automatically discovered by the kernel-crawler and periodically built by test-infra. The supported versions can be found at https://falcosecurity.github.io/kernel-crawler/?target=Minikube\u0026arch=x86_64. Falco currently retains previously-built kernel modules for download and continues to provide limited historical support as well.\nYou can follow the official Get Started! guide to install.\nView minikube Get Started! Guide\nNote: Ensure that you have installed kubectl.\nFalco with syscall source only In order to install Falco with the kernel module or the bpf probe:\nCreate the cluster with Minikube using a VM driver, in this case, Virtualbox:\nminikube start --driver=virtualbox Check that all pods are running:\nkubectl get pods --all-namespaces Add the Falco Helm repository and update the local Helm repository cache:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update Install Falco using Helm:\nhelm install falco \\ --set driver.kind=modern_ebpf \\ --set tty=true \\ falcosecurity/falco The output is similar to:\nNAME: falco LAST DEPLOYED: Wed Apr 17 08:19:53 2024 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Falco agents are spinning up on each node in your cluster. After a few seconds, they are going to start monitoring your containers looking for security issues. No further action should be required. Tip: You can easily forward Falco events to Slack, Kafka, AWS Lambda and more with falcosidekick. Full list of outputs: https://github.com/falcosecurity/charts/tree/master/charts/falcosidekick. You can enable its deployment with `--set falcosidekick.enabled=true` or in your values.yaml. See: https://github.com/falcosecurity/charts/blob/master/charts/falcosidekick/values.yaml for configuration values. Check the logs to ensure that Falco is running:\nkubectl logs -l app.kubernetes.io/name=falco --all-containers The output is similar to:\n{\u0026#34;level\u0026#34;:\u0026#34;INFO\u0026#34;,\u0026#34;msg\u0026#34;:\u0026#34;Resolving dependencies ...\u0026#34;,\u0026#34;timestamp\u0026#34;:\u0026#34;2024-04-17 06:19:49\u0026#34;} {\u0026#34;level\u0026#34;:\u0026#34;INFO\u0026#34;,\u0026#34;msg\u0026#34;:\u0026#34;Installing artifacts\u0026#34;,\u0026#34;refs\u0026#34;:[\u0026#34;ghcr.io/falcosecurity/rules/falco-rules:3\u0026#34;],\u0026#34;timestamp\u0026#34;:\u0026#34;2024-04-17 06:19:51\u0026#34;} {\u0026#34;level\u0026#34;:\u0026#34;INFO\u0026#34;,\u0026#34;msg\u0026#34;:\u0026#34;Preparing to pull artifact\u0026#34;,\u0026#34;ref\u0026#34;:\u0026#34;ghcr.io/falcosecurity/rules/falco-rules:3\u0026#34;,\u0026#34;timestamp\u0026#34;:\u0026#34;2024-04-17 06:19:51\u0026#34;} {\u0026#34;level\u0026#34;:\u0026#34;INFO\u0026#34;,\u0026#34;msg\u0026#34;:\u0026#34;Pulling layer 1e72f9c4d8fe\u0026#34;,\u0026#34;timestamp\u0026#34;:\u0026#34;2024-04-17 06:19:52\u0026#34;} {\u0026#34;level\u0026#34;:\u0026#34;INFO\u0026#34;,\u0026#34;msg\u0026#34;:\u0026#34;Pulling layer 2e91799fee49\u0026#34;,\u0026#34;timestamp\u0026#34;:\u0026#34;2024-04-17 06:19:52\u0026#34;} {\u0026#34;level\u0026#34;:\u0026#34;INFO\u0026#34;,\u0026#34;msg\u0026#34;:\u0026#34;Pulling layer d4c03e000273\u0026#34;,\u0026#34;timestamp\u0026#34;:\u0026#34;2024-04-17 06:19:52\u0026#34;} {\u0026#34;digest\u0026#34;:\u0026#34;ghcr.io/falcosecurity/rules/falco-rules@sha256:d4c03e000273a0168ee3d9b3dfb2174e667b93c9bfedf399b298ed70f37d623b\u0026#34;,\u0026#34;level\u0026#34;:\u0026#34;INFO\u0026#34;,\u0026#34;msg\u0026#34;:\u0026#34;Verifying signature for artifact\u0026#34;,\u0026#34;timestamp\u0026#34;:\u0026#34;2024-04-17 06:19:52\u0026#34;} {\u0026#34;level\u0026#34;:\u0026#34;INFO\u0026#34;,\u0026#34;msg\u0026#34;:\u0026#34;Signature successfully verified!\u0026#34;,\u0026#34;timestamp\u0026#34;:\u0026#34;2024-04-17 06:19:53\u0026#34;} {\u0026#34;file\u0026#34;:\u0026#34;falco_rules.yaml.tar.gz\u0026#34;,\u0026#34;level\u0026#34;:\u0026#34;INFO\u0026#34;,\u0026#34;msg\u0026#34;:\u0026#34;Extracting and installing artifact\u0026#34;,\u0026#34;timestamp\u0026#34;:\u0026#34;2024-04-17 06:19:53\u0026#34;,\u0026#34;type\u0026#34;:\u0026#34;rulesfile\u0026#34;} {\u0026#34;digest\u0026#34;:\u0026#34;sha256:d4c03e000273a0168ee3d9b3dfb2174e667b93c9bfedf399b298ed70f37d623b\u0026#34;,\u0026#34;directory\u0026#34;:\u0026#34;/rulesfiles\u0026#34;,\u0026#34;level\u0026#34;:\u0026#34;INFO\u0026#34;,\u0026#34;msg\u0026#34;:\u0026#34;Artifact successfully installed\u0026#34;,\u0026#34;name\u0026#34;:\u0026#34;ghcr.io/falcosecurity/rules/falco-rules:3\u0026#34;,\u0026#34;timestamp\u0026#34;:\u0026#34;2024-04-17 06:19:53\u0026#34;,\u0026#34;type\u0026#34;:\u0026#34;rulesfile\u0026#34;} Wed Apr 17 06:19:54 2024: Falco initialized with configuration file: /etc/falco/falco.yaml Wed Apr 17 06:19:54 2024: System info: Linux version 5.10.57 (jenkins@ubuntu-iso) (x86_64-minikube-linux-gnu-gcc.br_real (Buildroot 2021.02.12-1-gb75713b-dirty) 9.4.0, GNU ld (GNU Binutils) 2.35.2) #1 SMP Tue Nov 7 06:51:54 UTC 2023 Wed Apr 17 06:19:54 2024: Loading rules from file /etc/falco/falco_rules.yaml Wed Apr 17 06:19:54 2024: Hostname value has been overridden via environment variable to: minikube Wed Apr 17 06:19:54 2024: The chosen syscall buffer dimension is: 8388608 bytes (8 MBs) Wed Apr 17 06:19:54 2024: Starting health webserver with threadiness 4, listening on 0.0.0.0:8765 Wed Apr 17 06:19:54 2024: Loaded event sources: syscall Wed Apr 17 06:19:54 2024: Enabled event sources: syscall Wed Apr 17 06:19:54 2024: Opening \u0026#39;syscall\u0026#39; source with modern BPF probe. Wed Apr 17 06:19:54 2024: One ring buffer every \u0026#39;2\u0026#39; CPUs. Falco with multiple sources Here we run Falco in a minikube cluster with multiple sources: syscall and k8s_audit. The next steps show how to start a minikube cluster with the audit logs enabled and deploy Falco with the kernel module and the k8saudit plugin:\nFirst, we need to create a new folder under the configuration folder of minikube:\nmkdir -p ~/.minikube/files/etc/ssl/certs We are assuming that the minikube configuration folder lives in your home folder; otherwise, adjust the command according to your environment.\nLet's create the needed configuration files to enable the audit logs. We are going to create a new file under ~/.minikube/files/etc/ssl/certs named audit-policy.yaml and copy the required config into it. Copy the following snippet into your terminal shell:\ncat \u0026lt;\u0026lt; EOF \u0026gt; ~/.minikube/files/etc/ssl/certs/audit-policy.yaml apiVersion: audit.k8s.io/v1 # This is required. kind: Policy # Don\u0026#39;t generate audit events for all requests in RequestReceived stage. omitStages: - \u0026#34;RequestReceived\u0026#34; rules: # Log pod changes at RequestResponse level - level: RequestResponse resources: - group: \u0026#34;\u0026#34; # Resource \u0026#34;pods\u0026#34; doesn\u0026#39;t match requests to any subresource of pods, # which is consistent with the RBAC policy. resources: [\u0026#34;pods\u0026#34;, \u0026#34;deployments\u0026#34;] - level: RequestResponse resources: - group: \u0026#34;rbac.authorization.k8s.io\u0026#34; # Resource \u0026#34;pods\u0026#34; doesn\u0026#39;t match requests to any subresource of pods, # which is consistent with the RBAC policy. resources: [\u0026#34;clusterroles\u0026#34;, \u0026#34;clusterrolebindings\u0026#34;] # Log \u0026#34;pods/log\u0026#34;, \u0026#34;pods/status\u0026#34; at Metadata level - level: Metadata resources: - group: \u0026#34;\u0026#34; resources: [\u0026#34;pods/log\u0026#34;, \u0026#34;pods/status\u0026#34;] # Don\u0026#39;t log requests to a configmap called \u0026#34;controller-leader\u0026#34; - level: None resources: - group: \u0026#34;\u0026#34; resources: [\u0026#34;configmaps\u0026#34;] resourceNames: [\u0026#34;controller-leader\u0026#34;] # Don\u0026#39;t log watch requests by the \u0026#34;system:kube-proxy\u0026#34; on endpoints or services - level: None users: [\u0026#34;system:kube-proxy\u0026#34;] verbs: [\u0026#34;watch\u0026#34;] resources: - group: \u0026#34;\u0026#34; # core API group resources: [\u0026#34;endpoints\u0026#34;, \u0026#34;services\u0026#34;] # Don\u0026#39;t log authenticated requests to certain non-resource URL paths. - level: None userGroups: [\u0026#34;system:authenticated\u0026#34;] nonResourceURLs: - \u0026#34;/api*\u0026#34; # Wildcard matching. - \u0026#34;/version\u0026#34; # Log the request body of configmap changes in kube-system. - level: Request resources: - group: \u0026#34;\u0026#34; # core API group resources: [\u0026#34;configmaps\u0026#34;] # This rule only applies to resources in the \u0026#34;kube-system\u0026#34; namespace. # The empty string \u0026#34;\u0026#34; can be used to select non-namespaced resources. namespaces: [\u0026#34;kube-system\u0026#34;] # Log configmap changes in all other namespaces at the RequestResponse level. - level: RequestResponse resources: - group: \u0026#34;\u0026#34; # core API group resources: [\u0026#34;configmaps\u0026#34;] # Log secret changes in all other namespaces at the Metadata level. - level: Metadata resources: - group: \u0026#34;\u0026#34; # core API group resources: [\u0026#34;secrets\u0026#34;] # Log all other resources in core and extensions at the Request level. - level: Request resources: - group: \u0026#34;\u0026#34; # core API group - group: \u0026#34;extensions\u0026#34; # Version of group should NOT be included. # A catch-all rule to log all other requests at the Metadata level. - level: Metadata # Long-running requests like watches that fall under this rule will not # generate an audit event in RequestReceived. omitStages: - \u0026#34;RequestReceived\u0026#34; EOF Create the file webhook-config.yaml and save the required configuration needed by the k8s api-server to send the audit logs to Falco:\ncat \u0026lt;\u0026lt; EOF \u0026gt; ~/.minikube/files/etc/ssl/certs/webhook-config.yaml apiVersion: v1 kind: Config clusters: - name: falco cluster: # certificate-authority: /path/to/ca.crt # for https server: http://localhost:30007/k8s-audit contexts: - context: cluster: falco user: \u0026#34;\u0026#34; name: default-context current-context: default-context preferences: {} users: [] EOF Once the configuration files are in place we are ready to start the minikube cluster:\nminikube start \\ --extra-config=apiserver.audit-policy-file=/etc/ssl/certs/audit-policy.yaml \\ --extra-config=apiserver.audit-log-path=- \\ --extra-config=apiserver.audit-webhook-config-file=/etc/ssl/certs/webhook-config.yaml \\ --extra-config=apiserver.audit-webhook-batch-max-size=10 \\ --extra-config=apiserver.audit-webhook-batch-max-wait=5s \\ --cpus=4 \\ --driver=virtualbox We need at least 4 CPUs for the VM to deploy Falco with multiple sources! Add the Falco Helm repository and update the local Helm repository cache:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update Install Falco using the pre-set values file:\nhelm install falco \\ --set driver.kind=modern_ebpf \\ --set tty=true \\ --values=https://raw.githubusercontent.com/falcosecurity/charts/master/charts/falco/values-syscall-k8saudit.yaml \\ falcosecurity/falco Check that the Falco pod is up and running:\nkubectl get pods -l app.kubernetes.io/name=falco Execute the following command and keep the terminal open:\nkubectl logs -l app.kubernetes.io/name=falco -f The command will follow the log stream of the Falco pod by printing the logs as soon as Falco emits them. And make sure that the following lines are present:\nMon Oct 24 15:24:06 2022: Opening capture with plugin \u0026#39;k8saudit\u0026#39; Mon Oct 24 15:24:06 2022: Opening \u0026#39;syscall\u0026#39; source with modern BPF probe It means that Falco is running with the configured sources.\nTrigger some rules to check that Falco works as expected. Open a new terminal and make sure that your kubeconfig points to the minikube cluster. Then run:\nTrigger a k8saudit rule:\nkubectl create cm myconfigmap --from-literal=username=admin --from-literal=password=123456 In the terminal that we opened in step 8 we should see a log line like this:\n15:30:07.927586000: Warning K8s configmap with private credential (user=minikube-user verb=create resource=configmaps configmap=myconfigmap config={\u0026#34;password\u0026#34;:\u0026#34;123456\u0026#34;,\u0026#34;username\u0026#34;:\u0026#34;admin\u0026#34;}) Trigger a Falco rule:\nkubectl exec $(kubectl get pods -l app.kubernetes.io/name=falco -o name) -- cat /etc/shadow Check that a log similar to this one has been printed:\n15:32:04.318689836: Warning Sensitive file opened for reading by non-trusted program (file=/etc/shadow gparent=systemd ggparent=\u0026lt;NA\u0026gt; gggparent=\u0026lt;NA\u0026gt; evt_type=openat user=root user_uid=0 user_loginuid=-1 process=cat proc_exepath=/usr/bin/cat parent=containerd-shim command=cat /etc/shadow terminal=0 container_id=38e44b926166 container_image=falcosecurity/falco container_image_tag=0.40.0-debian container_name=k8s_falco_falco-bggd7_default_7bb0145f-dca5-452d-a670-01e23d839e5a_1 k8s_ns=\u0026lt;NA\u0026gt; k8s_pod_name=\u0026lt;NA\u0026gt;) kind kind lets you run Kubernetes on your local computer. This tool requires that you have Docker installed and configured. Currently not working directly on Mac with Linuxkit, but these directions work on Linux guest OS running kind.\nThe kind Quick Start page shows you what you need to do to get up and running with kind.\nView kind Quick Start Guide\nTo run Falco on a kind cluster is as follows:\nCreate a configuration file. For example: kind-config.yaml\nAdd the following to the file:\nkind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane extraMounts: # allow Falco to use devices provided by the kernel module - hostPath: /dev containerPath: /dev # allow Falco to use the Docker unix socket - hostPath: /var/run/docker.sock containerPath: /var/run/docker.sock Create the cluster by specifying the configuration file:\nkind create cluster --config=./kind-config.yaml Deploy Falco with Helm.\nMicroK8s MicroK8s is the smallest, fastest multi-node Kubernetes. Single-package fully conformant lightweight Kubernetes that works on Linux, Windows, and Mac. Perfect for: Developer workstations, IoT, Edge, CI/CD.\nYou can follow the official Getting Started guide to install.\nOnce the MicroK8s cluster is up and running, you can deploy Falco with Helm.\n","summary":"","tags":null,"title":"Learning Environments","url":"https://v0-43--falcosecurity.netlify.app/docs/getting-started/learning-environments/"},{"category":"docs","content":"In some cases, rules may need to contain special characters like (, spaces, etc. For example, you may need to look for a proc.name of (systemd), including the surrounding parentheses.\nYou can use \u0026quot; to capture these special characters. Here's an example:\n- rule: Any Open Activity by Systemd desc: Detects all open events by systemd. condition: evt.type=open and proc.name=\u0026#34;(systemd)\u0026#34; or proc.name=systemd output: \u0026#34;File opened by systemd | user=%user.name command=%proc.cmdline file=%fd.name priority: WARNING When including items in lists, ensure that the double quotes are not interpreted from your YAML file by surrounding the quoted string with single quotes. Here's an example:\n- list: systemd_procs items: [systemd, \u0026#39;\u0026#34;(systemd)\u0026#34;\u0026#39;] - rule: Any Open Activity by Systemd desc: Detects all open events by systemd. condition: evt.type=open and proc.name in (systemd_procs) output: \u0026#34;File opened by systemd | user=%user.name command=%proc.cmdline file=%fd.name\u0026#34; priority: WARNING ","summary":"","tags":null,"title":"Escaping Special Characters","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/special-characters/"},{"category":"docs","content":"Falco provides default rules maintained by the maintainers with contributions from the community. More information on this page.\nThis list presents the default rules based on syscall events.\nBy default, only the stable rules are loaded by Falco, you can install the sandbox or incubating rules by referencing them in the Helm chart:\nhelm install falco falcosecurity/falco \\ --set \u0026#34;falcoctl.config.artifact.install.refs={falco-rules:3,falco-incubating-rules:4,falco-sandbox-rules:4}\u0026#34; \\ --set \u0026#34;falcoctl.config.artifact.follow.refs={falco-rules:3,falco-incubating-rules:4,falco-sandbox-rules:4}\u0026#34; \\ --set \u0026#34;falco.rules_files={/etc/falco/k8s_audit_rules.yaml,/etc/falco/rules.d,/etc/falco/falco_rules.yaml,/etc/falco/falco-incubating_rules.yaml,/etc/falco/falco-sandbox_rules.yaml}\u0026#34; Where the option falcoctl.config.artifact.install.refs governs which rules are downloaded at startup, falcoctl.config.artifact.follow.refs identifies which rules are automatically updated and falco.rules_files indicates which rules are loaded by the engine.\nYou can find all the rules in their official repository.\n\u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Disallowed_SSH_Connection\u0026gt; Disallowed SSH Connection \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity deprecated chip small\u0026quot;\u0026gt;deprecated\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect any new SSH connection on port 22 to a host other than those in an allowed list of hosts. This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely crucial in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging due to the potential for noise. Condition:\ninbound_outbound and ssh_port and not allowed_ssh_hosts Output:\nDisallowed SSH Connection (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info) Maturity: deprecated Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_deprecated\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_lateral_movement\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1021.004\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Disallowed_SSH_Connection /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Unexpected_outbound_connection_destination\u0026gt; Unexpected outbound connection destination \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity deprecated chip small\u0026quot;\u0026gt;deprecated\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect any outbound connection to a destination outside of an allowed set of ips, networks, or domain names. This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely crucial in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging due to the potential for noise. Condition:\noutbound and not ((fd.sip in (allowed_outbound_destination_ipaddrs)) or (fd.snet in (allowed_outbound_destination_networks)) or (fd.sip.name in (allowed_outbound_destination_domains))) Output:\nDisallowed outbound connection destination (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info) Maturity: deprecated Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_deprecated\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_command_and_control\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0011\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Unexpected_outbound_connection_destination /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Outbound_or_Inbound_Traffic_not_to_Authorized_Server_Process_and_Port\u0026gt; Outbound or Inbound Traffic not to Authorized Server Process and Port \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity deprecated chip small\u0026quot;\u0026gt;deprecated\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect traffic to an unauthorized server process and port within pre-defined containers. This rule absolutely requires profiling your environment beforehand and also necessitates adjusting the list of containers to which this rule will be applied. The current expression logic will never evaluate to true unless the list is populated. Network-based rules are extremely crucial in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging due to the potential for noise. Notably, this rule is challenging to operationalize. Condition:\ninbound_outbound and container and container.image.repository in (allowed_image) and not proc.name in (authorized_server_binary) and not fd.sport in (authorized_server_port) Output:\nNetwork connection outside authorized port and binary (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info) Maturity: deprecated Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_deprecated\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_discovery\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0011\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; NIST_800-53_CM-7\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Outbound_or_Inbound_Traffic_not_to_Authorized_Server_Process_and_Port /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Outbound_Connection_to_C2_Servers\u0026gt; Outbound Connection to C2 Servers \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity deprecated chip small\u0026quot;\u0026gt;deprecated\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect outbound connections to command and control servers using a list of IP addresses and fully qualified domain names (FQDNs). This rule absolutely requires profiling your environment beforehand and also necessitates adjusting the template lists. The current expression logic will never evaluate to true unless the lists are populated. Network-based rules are extremely crucial in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging due to the potential for noise. Notably, this rule is challenging to operationalize. Condition:\noutbound and ((fd.sip in (c2_server_ip_list)) or (fd.sip.name in (c2_server_fqdn_list))) Output:\nOutbound connection to C2 server (c2_domain=%fd.sip.name c2_addr=%fd.sip connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info) Maturity: deprecated Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_deprecated\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_command_and_control\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0011\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Outbound_Connection_to_C2_Servers /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Modify_Shell_Configuration_File\u0026gt; Modify Shell Configuration File \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect attempts to modify shell configuration files, primarily aimed at establishing persistence by automatically inserting commands into scripts executed by shells. The upstream rule excludes shell processes because they often create unnecessary noise. However, this might lead to missed detections. To customize the rule for your situation, you can fine-tune it using enhanced profiling. For example, you might want to only consider interactive shell processes (where proc.tty != 0). Condition:\nopen_write and (fd.filename in (shell_config_filenames) or fd.name in (shell_config_files) or fd.directory in (shell_config_directories)) and not proc.name in (shell_binaries) and not exe_running_docker_save and not user_known_shell_config_modifiers Output:\nA shell configuration file has been modified | file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1546.004\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Modify_Shell_Configuration_File /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Schedule_Cron_Jobs\u0026gt; Schedule Cron Jobs \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect scheduled cron jobs; this is a highly generic detection and certainly needs adjustments and profiling in your environment before operationalization. Simultaneously, exploiting the functionality of cron jobs is among one of the oldest TTPs used by adversaries. Condition:\n((open_write and fd.name startswith /etc/cron) or (spawned_process and proc.name = \u0026quot;crontab\u0026quot;)) and not user_known_cron_jobs Output:\nCron jobs were scheduled to run | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1053.003\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Schedule_Cron_Jobs /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Read_ssh_information\u0026gt; Read ssh information \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;This rule identifies attempts to read files within ssh directories using programs that are not related to ssh. It\u0026amp;#39;s a simple and versatile detection method that works well alongside more specific rules focused on sensitive file access. You have a couple of options for using this rule effectively: you can adjust the specialized rules to cover all the important scenarios and ensure precedence in rule smatching for those, or you can analyze the combined view of ssh-related file access across various rules on your downstream computing platform. Just like with other rules, you can narrow down monitoring to specific processes, or you can limit it to interactive access only. Condition:\n(open_read or open_directory) and (user_ssh_directory or fd.name startswith /root/.ssh) and not user_known_read_ssh_information_activities and not proc.name in (ssh_binaries) Output:\nssh-related file/directory read by non-ssh program | file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_collection\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1005\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Read_ssh_information /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=DB_program_spawned_process\u0026gt; DB program spawned process \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;A program related to the database server creates an unexpected child process (other than itself). This is not supposed to happen and often follows SQL injection attacks. This behavioral detection could indicate potential unauthorized data extraction or tampering with the database. Condition:\nspawned_process and proc.pname in (db_server_binaries) and not proc.name in (db_server_binaries) and not postgres_running_wal_e and not user_known_db_spawned_processes Output:\nDatabase-related program spawned process other than itself | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; database\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1190\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#DB_program_spawned_process /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Change_thread_namespace\u0026gt; Change thread namespace \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;An attempt to alter the namespace of a process (often performed while creating a container) through the setns syscall. Conversely, the same syscall setns is triggered when an unauthorized attempt is made to break out from the container to the host, for example, when using commands like `nsenter --target 1` and similar ones. Recommending to profile your environment and refine this rule for effective operationalization. Condition:\nevt.type=setns and proc_name_exists and not (container.id=host and proc.name in (docker_binaries, k8s_binaries, lxd_binaries, nsenter)) and not proc.name in (sysdigcloud_binaries, sysdig, calico, oci-umount, cilium-cni, network_plugin_binaries) and not proc.name in (user_known_change_thread_namespace_binaries) and not proc.name startswith \u0026quot;runc\u0026quot; and not proc.cmdline startswith \u0026quot;containerd\u0026quot; and not proc.pname in (sysdigcloud_binaries, hyperkube, kubelet, protokube, dockerd, tini, aws) and not java_running_sdjagent and not kubelet_running_loopback and not rancher_agent and not rancher_network_manager and not calico_node and not weaveworks_scope and not user_known_change_thread_namespace_activities Output:\nNamespace change (setns) by unexpected program | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1611\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Change_thread_namespace /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Change_namespace_privileges_via_unshare\u0026gt; Change namespace privileges via unshare \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Unprivileged users in containers may not have CAP_SYS_ADMIN or other elevated privileges. However, they can use the unshare system call with CLONE_NEWNS or CLONE_NEWUSER to create or clone a namespace or user with the necessary privileges to conduct further attacks. It is best practice to block the unshare system call via seccomp if it is not needed. Misuse of unshare can be related to misconfigured Kubernetes clusters, for example. Condition:\nevt.type=unshare and container and not thread.cap_permitted contains CAP_SYS_ADMIN Output:\nChange namespace privileges via unshare | res=%evt.res evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1611\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Change_namespace_privileges_via_unshare /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Launch_Privileged_Container\u0026gt; Launch Privileged Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority info chip small\u0026quot;\u0026gt;INFO\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect the initial process initiation within a privileged container, with exemptions for known and trusted images. This rule primarily serves as an excellent auditing mechanism since highly privileged containers, when compromised, can result in significant harm. For instance, if another rule triggers within such a privileged container, it could be seen as more suspicious, prompting a closer inspection. Condition:\ncontainer_started and container.privileged=true and not falco_privileged_containers and not user_privileged_containers and not redhat_image Output:\nPrivileged container started | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: INFO Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; cis\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1610\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; PCI_DSS_10.2.5\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Launch_Privileged_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Launch_Excessively_Capable_Container\u0026gt; Launch Excessively Capable Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority info chip small\u0026quot;\u0026gt;INFO\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Identify containers that start with a powerful set of capabilities, with exceptions for recognized trusted images. Similar to the \u0026amp;#34;Launch Privileged Container\u0026amp;#34; rule, this functions as a robust auditing rule. Compromised highly privileged containers can lead to substantial harm. For instance, if another rule is triggered within such a container, it might raise suspicion, prompting closer scrutiny. Condition:\ncontainer_started and excessively_capable_container and not falco_privileged_containers and not user_privileged_containers Output:\nExcessively capable container started | cap_permitted=%thread.cap_permitted evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: INFO Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; cis\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1610\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Launch_Excessively_Capable_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=System_procs_network_activity\u0026gt; System procs network activity \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect any unexpected network activity performed by system binaries that typically shouldn\u0026amp;#39;t perform network activity, including coreutils binaries (like sleep, mkdir, who, date, and others) or user management binaries (such as login, systemd, usermod, deluser, adduser, chpasswd, and others). This serves as a valuable baseline detection for network-related activities. Condition:\ninbound_outbound and fd.sockfamily = ip and (system_procs or proc.name in (shell_binaries)) and not proc.name in (known_system_procs_network_activity_binaries) and not login_doing_dns_lookup and not user_expected_system_procs_network_activity_conditions Output:\nKnown system binary sent/received network traffic | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#System_procs_network_activity /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Program_run_with_disallowed_http_proxy_env\u0026gt; Program run with disallowed http proxy env \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect curl or wget usage with HTTP_PROXY environment variable. Attackers can manipulate the HTTP_PROXY variable\u0026amp;#39;s value to redirect application\u0026amp;#39;s internal HTTP requests. This could expose sensitive information like authentication keys and private data. Condition:\nspawned_process and http_proxy_procs and proc.env icontains HTTP_PROXY and not allowed_ssh_proxy_env Output:\nCurl or wget run with disallowed HTTP_PROXY environment variable | env=%proc.env evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; users\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1204\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Program_run_with_disallowed_http_proxy_env /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Unexpected_UDP_Traffic\u0026gt; Unexpected UDP Traffic \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detecting UDP traffic on ports other than 53 (DNS) or other commonly used ports. Misusing UDP is a known TTP among attackers. Monitoring unusual network activity is highly valuable but often generates significant noise, as is the case with this detection. Condition:\ninbound_outbound and fd.l4proto=udp and not expected_udp_traffic Output:\nUnexpected UDP Traffic Seen | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_exfiltration\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0011\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Unexpected_UDP_Traffic /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Non_sudo_setuid\u0026gt; Non sudo setuid \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect attempts to change users through the use of setuid, with exceptions for sudo/su. The users \u0026amp;#34;root\u0026amp;#34; and \u0026amp;#34;nobody\u0026amp;#34; using setuid on themselves are also excluded, as setuid calls in these cases typically involve reducing privileges. By setting the setuid bit, an attacker could execute code in a different user\u0026amp;#39;s context, potentially with higher privileges. One drawback is the potential for noise, as many applications legitimately use this approach. Condition:\nevt.type=setuid and (known_user_in_container or not container) and not (user.name=root or user.uid=0) and not somebody_becoming_themselves and not proc.name in (known_setuid_binaries, userexec_binaries, mail_binaries, docker_binaries, nomachine_binaries) and not proc.name startswith \u0026quot;runc:\u0026quot; and not java_running_sdjagent and not nrpe_becoming_nagios and not user_known_non_sudo_setuid_conditions Output:\nUnexpected setuid call by non-sudo, non-root program | arg_uid=%evt.arg.uid evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; users\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1548.001\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Non_sudo_setuid /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=User_mgmt_binaries\u0026gt; User mgmt binaries \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect activity by any programs that can manage users, passwords, or permissions (such as login, systemd, usermod, deluser, adduser, chpasswd, and others). sudo and su are excluded. Activity in containers is also excluded -- some containers create custom users on top of a base linux distribution at startup. Some innocuous command lines that don\u0026amp;#39;t actually change anything are excluded. You might want to consider applying this rule to container actions as well. Condition:\nspawned_process and not container and proc.name in (user_mgmt_binaries) and not proc.name in (su, sudo, lastlog, nologin, unix_chkpwd) and not proc.pname in (cron_binaries, systemd, systemd.postins, udev.postinst, run-parts) and not proc.cmdline startswith \u0026quot;passwd -S\u0026quot; and not proc.cmdline startswith \u0026quot;useradd -D\u0026quot; and not proc.cmdline startswith \u0026quot;systemd --version\u0026quot; and not run_by_qualys and not run_by_sumologic_securefiles and not run_by_yum and not run_by_ms_oms and not run_by_google_accounts_daemon and not chage_list and not user_known_user_management_activities Output:\nUser management binary command run outside of container | gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; users\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; software_mgmt\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1098\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#User_mgmt_binaries /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Create_files_below_dev\u0026gt; Create files below dev \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect the creation of files under /dev except for authorized device management programs. This can reveal rootkits hiding files in /dev. Additionally, consider the \u0026amp;#34;Execution from /dev/shm\u0026amp;#34; rule. The upstream rule already covers some tuning scenarios that you can further expand upon. Condition:\n(evt.type = creat or (evt.type in (open,openat,openat2))) and evt.arg.flags contains O_CREAT and fd.directory = /dev and not proc.name in (dev_creation_binaries) and not fd.name in (allowed_dev_files) and not fd.name startswith /dev/tty and not user_known_create_files_below_dev_activities Output:\nFile created below /dev by untrusted program | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1543\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Create_files_below_dev /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Contact_EC2_Instance_Metadata_Service_From_Container\u0026gt; Contact EC2 Instance Metadata Service From Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detects attempts to communicate with the EC2 Instance Metadata Service from a container. This detection is narrowly focused and might not apply to your environment. In addition, it could generate noise and require fine-tuning. Condition:\noutbound and container and fd.sip=\u0026quot;169.254.169.254\u0026quot; and not ec2_metadata_containers Output:\nOutbound connection to EC2 instance metadata service | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; aws\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_credential_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1552.005\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Contact_EC2_Instance_Metadata_Service_From_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Contact_cloud_metadata_service_from_container\u0026gt; Contact cloud metadata service from container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detects attempts to communicate with the Cloud Instance Metadata Service from a container. This detection is narrowly focused and might not apply to your environment. In addition, it could generate noise and require fine-tuning. Condition:\noutbound and container and fd.sip=\u0026quot;169.254.169.254\u0026quot; and not user_known_metadata_access Output:\nOutbound connection to cloud instance metadata service | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_discovery\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1565\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Contact_cloud_metadata_service_from_container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Launch_Package_Management_Process_in_Container\u0026gt; Launch Package Management Process in Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect package management processes executed within containers. An excellent auditing rule to monitor general drifts in containers. Particularly useful for newer rules like \u0026amp;#34;Drop and execute new binary in container\u0026amp;#34; during incident response investigations. This helps identify common anti-patterns of ad-hoc debugging. Simultaneously, to maintain optimal hygiene, it\u0026amp;#39;s recommended to prevent container drifts and instead opt for redeploying new containers. Condition:\nspawned_process and container and user.name != \u0026quot;_apt\u0026quot; and package_mgmt_procs and not package_mgmt_ancestor_procs and not user_known_package_manager_in_container and not pkg_mgmt_in_kube_proxy Output:\nPackage management process launched in container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; software_mgmt\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1505\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Launch_Package_Management_Process_in_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Launch_Suspicious_Network_Tool_in_Container\u0026gt; Launch Suspicious Network Tool in Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect network tools (like netcat, nmap, tcpdump, socat, and more) launched within containers without any additional filters. This serves as a valuable general detection, but it\u0026amp;#39;s recommended to invest engineering effort to fine-tune it and prevent a high volume of legitimate logs. This rule complements the more specific \u0026amp;#34;Netcat Remote Code Execution in Container\u0026amp;#34; rule. Condition:\nspawned_process and container and network_tool_procs and not user_known_network_tool_activities Output:\nNetwork tool launched in container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Launch_Suspicious_Network_Tool_in_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Launch_Suspicious_Network_Tool_on_Host\u0026gt; Launch Suspicious Network Tool on Host \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect network tools (like netcat, nmap, tcpdump, socat, and more) launched within containers without any additional filters. This serves as a valuable general detection, but it\u0026amp;#39;s recommended to invest engineering effort to fine-tune it and prevent a high volume of legitimate logs. The host equivalent of \u0026amp;#34;Launch Suspicious Network Tool in Container.\u0026amp;#34;. Condition:\nspawned_process and not container and network_tool_procs and not user_known_network_tool_activities Output:\nNetwork tool launched on host | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Launch_Suspicious_Network_Tool_on_Host /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Delete_or_rename_shell_history\u0026gt; Delete or rename shell history \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect shell history deletion, frequently used by unsophisticated adversaries to eliminate evidence. Note that it can also trigger when exiting a Terminal shell, such as with `kubectl exec`, which may introduce some noise. Condition:\n(modify_shell_history or truncate_shell_history) and not var_lib_docker_filepath and not proc.name in (docker_binaries) Output:\nShell history deleted or renamed | file=%fd.name name=%evt.arg.name path=%evt.arg.path oldpath=%evt.arg.oldpath evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_defense_evasion\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1070\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Delete_or_rename_shell_history /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Set_Setuid_or_Setgid_bit\u0026gt; Set Setuid or Setgid bit \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;This rule is focused on detecting the use of setuid or setgid bits set via chmod. These bits, when set for an application, result in the application running with the privileges of the owning user or group. By enabling the setuid or setgid bits, an attacker could run code in a different user\u0026amp;#39;s context, possibly with elevated privileges. However, there\u0026amp;#39;s a trade-off with noise, given that numerous applications legitimately run chmod. This rule is related to the \u0026amp;#34;Non sudo setuid\u0026amp;#34; rule. Condition:\nchmod and (evt.arg.mode contains \u0026quot;S_ISUID\u0026quot; or evt.arg.mode contains \u0026quot;S_ISGID\u0026quot;) and not proc.name in (user_known_chmod_applications) and not exe_running_docker_save and not user_known_set_setuid_or_setgid_bit_conditions Output:\nSetuid or setgid bit is set via chmod | fd=%evt.arg.fd filename=%evt.arg.filename mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; users\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1548.001\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Set_Setuid_or_Setgid_bit /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Launch_Remote_File_Copy_Tools_in_Container\u0026gt; Launch Remote File Copy Tools in Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect remote file copy tools (like rsync, scp, sftp, dcp) launched within a container, potentially indicating data exfiltration. Suggest refining this rule to accommodate legitimate use cases. Condition:\nspawned_process and container and remote_file_copy_procs and not user_known_remote_file_copy_activities Output:\nRemote file copy tool launched in container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_exfiltration\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1020\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Launch_Remote_File_Copy_Tools_in_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Network_Connection_outside_Local_Subnet\u0026gt; Network Connection outside Local Subnet \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect network traffic (inbound or outbound) from a container to a destination outside the local subnet. To operationalize this rule, profile your environment and update the template macro namespace_scope_network_only_subnet. Customizing network-related rules usually demands substantial engineering effort to ensure their functionality. Condition:\ninbound_outbound and container and k8s.ns.name in (namespace_scope_network_only_subnet) and not network_local_subnet Output:\nNetwork connection outside local subnet | fd_rip_name=%fd.rip.name fd_lip_name=%fd.lip.name fd_cip_name=%fd.cip.name fd_sip_name=%fd.sip.name connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_discovery\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1046\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; PCI_DSS_6.4.2\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Network_Connection_outside_Local_Subnet /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Mount_Launched_in_Privileged_Container\u0026gt; Mount Launched in Privileged Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect filesystem mounts (using the mount binary) within a privileged container. Due to the elevated privileges, this action could be one of the TTPs used in an attempt to escape from a container to the host. This type of action is often preceded by reconnaissance activities, for which you can also create custom rules. Condition:\nspawned_process and container and container.privileged=true and proc.name=mount and not mount_info and not known_gke_mount_in_privileged_containers and not known_aks_mount_in_privileged_containers and not known_eks_mount_in_privileged_containers and not user_known_mount_in_privileged_containers Output:\nMount was executed inside a privileged container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; cis\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1611\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Mount_Launched_in_Privileged_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Launch_Ingress_Remote_File_Copy_Tools_in_Container\u0026gt; Launch Ingress Remote File Copy Tools in Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect ingress remote file copy tools (such as curl or wget) launched inside containers. This rule can be considered a valuable auditing tool, but it has the potential to generate notable noise and requires careful profiling before full operationalization. Condition:\nspawned_process and container and (ingress_remote_file_copy_procs or curl_download) and not user_known_ingress_remote_file_copy_activities Output:\nIngress remote file copy tool launched in container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_command_and_control\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0011\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Launch_Ingress_Remote_File_Copy_Tools_in_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Read_environment_variable_from_/proc_files\u0026gt; Read environment variable from /proc files \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;An attempt to read process environment variables from /proc files. The consequences are akin to accessing traditional sensitive files, as sensitive data, including secrets, might be stored in environment variables. Understanding your environment, such as identifying critical namespaces, and incorporating extra filtering statements to alert exclusively for those, can enhance the rule\u0026amp;#39;s effectiveness. Condition:\nopen_read and container and (fd.name glob /proc/*/environ) and not proc.name in (known_binaries_to_read_environment_variables_from_proc_files) Output:\nEnvironment variables were retrieved from /proc files | file=%fd.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_discovery\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1083\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Read_environment_variable_from_%2fproc_files /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Exfiltrating_Artifacts_via_Kubernetes_Control_Plane\u0026gt; Exfiltrating Artifacts via Kubernetes Control Plane \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect the copying of artifacts from a container\u0026amp;#39;s file system using the Kubernetes control plane (kubectl cp). This rule can identify potential exfiltration of application secrets from containers\u0026amp;#39; file systems, potentially revealing the outcomes of unauthorized access and control plane misuse via stolen identities (such as stolen credentials like Kubernetes serviceaccount tokens). Can be customized by the adopter to only monitor specific artifact paths, containers, or namespaces as needed. Condition:\nopen_read and container and proc.name=tar and container_entrypoint and proc.tty=0 and not system_level_side_effect_artifacts_kubectl_cp Output:\nExfiltrating Artifacts via Kubernetes Control Plane | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_exfiltration\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0010\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Exfiltrating_Artifacts_via_Kubernetes_Control_Plane /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Adding_ssh_keys_to_authorized_keys\u0026gt; Adding ssh keys to authorized_keys \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;After gaining access, attackers can modify the authorized_keys file to maintain persistence on a victim host. Where authorized_keys files are modified via cloud APIs or command line interfaces, an adversary may achieve privilege escalation on the target virtual machine if they add a key to a higher-privileged user. This rules aims at detecting any modification to the authorized_keys file, that is usually located under the .ssh directory in any user\u0026amp;#39;s home directory. This rule complements the more generic auditing rule \u0026amp;#34;Read ssh information\u0026amp;#34; by specifically detecting the writing of new, potentially attacker-provided keys. Condition:\nopen_write and (user_ssh_directory or fd.name startswith /root/.ssh) and fd.name endswith authorized_keys and not proc.name in (ssh_binaries) Output:\nAdding ssh keys to authorized_keys | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1098.004\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Adding_ssh_keys_to_authorized_keys /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Potential_Local_Privilege_Escalation_via_Environment_Variables_Misuse\u0026gt; Potential Local Privilege Escalation via Environment Variables Misuse \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Process run with suspect environment variable that could be attempting privilege escalation. One use case is detecting the use of the GLIBC_TUNABLES environment variable, which could be used for privilege escalation on systems running vulnerable glibc versions. Only known and carefully profiled processes that legitimately exhibit this behavior should be excluded from this rule. This rule is expected to trigger on every attempt, even failed ones. Condition:\nspawned_process and glibc_tunables_env Output:\nProcess run with suspect environment variable which could be attempting privilege escalation | env=%proc.env evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; users\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0004\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Potential_Local_Privilege_Escalation_via_Environment_Variables_Misuse /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Backdoored_library_loaded_into_SSHD_(CVE-2024-3094)\u0026gt; Backdoored library loaded into SSHD (CVE-2024-3094) \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;This rule detects possible CVE-2024-3094 exploitation when the SSH daemon process loads a vulnerable version of the liblzma library. An attacker could exploit this to interfere with authentication in sshd via systemd, potentially compromising sensitive data or escalating their privileges.\u0026lt;/code\u0026gt;\u0026lt;/pre\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;conditionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Condition:\u0026lt;/span\u0026gt;\u0026lt;br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;open_read and proc.name=sshd and (fd.name contains \u0026amp;#34;liblzma.so.5.6.0\u0026amp;#34; or fd.name contains \u0026amp;#34;liblzma.so.5.6.1\u0026amp;#34;) Output:\nSSHD loaded a backdoored version of liblzma library %fd.name with parent %proc.pname and cmdline %proc.cmdline | process=%proc.name parent=%proc.pname file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid proc_exepath=%proc.exepath command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: incubating Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_initial_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1556\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Backdoored_library_loaded_into_SSHD_%28CVE-2024-3094%29 /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=BPF_Program_Not_Profiled\u0026gt; BPF Program Not Profiled \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity incubating chip small\u0026quot;\u0026gt;incubating\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;BPF is a kernel technology that can be misused for malicious purposes, like \u0026amp;#34;Linux Kernel Module Injection\u0026amp;#34;. This rule should be considered an auditing rule to notify you of any unprofiled BPF tools running in your environment. However, it requires customization after profiling your environment. BPF-powered agents make bpf syscalls all the time, so this rule only sends logs for BPF_PROG_LOAD calls (bpf cmd=5) in the enter event. If you also want to log whether the syscall failed or succeeded, remove the direction filter and add the evt.arg.res_or_fd output field. Condition:\nevt.type=bpf and (evt.arg.cmd=5 or evt.arg.cmd=BPF_PROG_LOAD) and not bpf_profiled_procs Output:\nBPF Program Not Profiled | bpf_cmd=%evt.arg.cmd evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: incubating Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_incubating\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0003\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#BPF_Program_Not_Profiled /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Unexpected_inbound_connection_source\u0026gt; Unexpected inbound connection source \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect any inbound connection from a source outside of an allowed set of ips, networks, or domain names. This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely crucial in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging due to the potential for noise. Condition:\ninbound and not ((fd.cip in (allowed_inbound_source_ipaddrs)) or (fd.cnet in (allowed_inbound_source_networks)) or (fd.cip.name in (allowed_inbound_source_domains))) Output:\nDisallowed inbound connection source | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_command_and_control\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0011\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Unexpected_inbound_connection_source /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Read_Shell_Configuration_File\u0026gt; Read Shell Configuration File \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;This rule detects attempts made by non-shell programs to read shell configuration files. It offers additional generic auditing. It serves as a baseline detection alert for unusual shell configuration file accesses. The rule \u0026amp;#34;Modify Shell Configuration File\u0026amp;#34; might be more relevant and adequate for your specific cases. Condition:\nopen_read and (fd.filename in (shell_config_filenames) or fd.name in (shell_config_files) or fd.directory in (shell_config_directories)) and not proc.name in (shell_binaries) Output:\nA shell configuration file was read by a non-shell program | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_discovery\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1546.004\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Read_Shell_Configuration_File /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Update_Package_Repository\u0026gt; Update Package Repository \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;This rule generically detects updates to package repositories and can be seen as an auditing measure. Recommend evaluating its relevance for your specific environment. Condition:\n((open_write and access_repositories) or (modify and modify_repositories)) and not package_mgmt_procs and not package_mgmt_ancestor_procs and not exe_running_docker_save and not user_known_update_package_registry Output:\nRepository files get updated | newpath=%evt.arg.newpath file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1072\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Update_Package_Repository /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Write_below_binary_dir\u0026gt; Write below binary dir \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Trying to write to any file below specific binary directories can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. Condition:\nopen_write and bin_dir and not package_mgmt_procs and not exe_running_docker_save and not python_running_get_pip and not python_running_ms_oms and not user_known_write_below_binary_dir_activities Output:\nFile below a known binary directory opened for writing | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1543\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Write_below_binary_dir /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Write_below_monitored_dir\u0026gt; Write below monitored dir \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Trying to write to any file below a set of monitored directories can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. Condition:\nopen_write and monitored_dir and not package_mgmt_procs and not coreos_write_ssh_dir and not exe_running_docker_save and not python_running_get_pip and not python_running_ms_oms and not google_accounts_daemon_writing_ssh and not cloud_init_writing_ssh and not user_known_write_monitored_dir_conditions Output:\nFile below a monitored directory opened for writing | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1543\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Write_below_monitored_dir /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Write_below_etc\u0026gt; Write below etc \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Trying to write to any file below /etc can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. Condition:\nwrite_etc_common Output:\nFile below /etc opened for writing | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1098\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Write_below_etc /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Write_below_root\u0026gt; Write below root \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Trying to write to any file directly below / or /root can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. Lastly, this rule stands out as potentially the noisiest one among rules related to \u0026amp;#34;write below. Condition:\nopen_write and root_dir and proc_name_exists and not fd.name in (known_root_files) and not fd.directory pmatch (known_root_directories) and not exe_running_docker_save and not gugent_writing_guestagent_log and not dse_writing_tmp and not zap_writing_state and not airflow_writing_state and not rpm_writing_root_rpmdb and not maven_writing_groovy and not chef_writing_conf and not kubectl_writing_state and not cassandra_writing_state and not galley_writing_state and not calico_writing_state and not rancher_writing_root and not runc_writing_exec_fifo and not mysqlsh_writing_state and not known_root_conditions and not user_known_write_root_conditions and not user_known_write_below_root_activities Output:\nFile below / or /root opened for writing | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0003\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Write_below_root /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Write_below_rpm_database\u0026gt; Write below rpm database \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Trying to write to the rpm database by any non-rpm related program can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. Condition:\nopen_write and fd.name startswith /var/lib/rpm and not rpm_procs and not ansible_running_python and not python_running_chef and not exe_running_docker_save and not amazon_linux_running_python_yum and not user_known_write_rpm_database_activities Output:\nrpm database opened for writing by a non-rpm program | file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; software_mgmt\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1072\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Write_below_rpm_database /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Modify_binary_dirs\u0026gt; Modify binary dirs \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Trying to modify any file below a set of binary directories can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. Condition:\nmodify and bin_dir_rename and not package_mgmt_procs and not exe_running_docker_save and not user_known_modify_bin_dir_activities Output:\nFile below known binary directory renamed/removed | file=%fd.name pcmdline=%proc.pcmdline evt_args=%evt.args evt_type=%evt.type evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_defense_evasion\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1222.002\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Modify_binary_dirs /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Mkdir_binary_dirs\u0026gt; Mkdir binary dirs \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Trying to create a directory below a set of binary directories can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. Condition:\nmkdir and bin_dir_mkdir and not package_mgmt_procs and not user_known_mkdir_bin_dir_activities and not exe_running_docker_save Output:\nDirectory below known binary directory created | directory=%evt.arg.path evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1222.002\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Mkdir_binary_dirs /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Launch_Sensitive_Mount_Container\u0026gt; Launch Sensitive Mount Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority info chip small\u0026quot;\u0026gt;INFO\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect the initial process launched within a container that has a mount from a sensitive host directory (e.g. /proc). Exceptions are made for known trusted images. This rule holds value for generic auditing; however, its noisiness varies based on your environment. Condition:\ncontainer_started and sensitive_mount and not falco_sensitive_mount_containers and not user_sensitive_mount_containers Output:\nContainer with sensitive mount started | mounts=%container.mounts evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: INFO Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; cis\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1610\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Launch_Sensitive_Mount_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Launch_Disallowed_Container\u0026gt; Launch Disallowed Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect the initial process launched within a container that is not in a list of allowed containers. This rule holds value for generic auditing; however, this rule requires a good understanding of your setup and consistent effort to keep the list of allowed containers current. In some situations, this can be challenging to manage. Condition:\ncontainer_started and not allowed_containers Output:\nContainer started and not in allowed list | evt_type=%evt.type user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_lateral_movement\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1610\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Launch_Disallowed_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Interpreted_procs_inbound_network_activity\u0026gt; Interpreted procs inbound network activity \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Any inbound network activity performed by any interpreted program (perl, python, ruby, etc.). While it offers broad coverage and behavioral insights, operationalizing it effectively requires significant time and might result in a moderate level of noise. Suggesting customizing this rule to be more specific. For example, you could set it up to alert only for important namespaces after studying their usual behavior. Condition:\ninbound and interpreted_procs Output:\nInterpreted program received/listened for network traffic | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_exfiltration\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0011\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Interpreted_procs_inbound_network_activity /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Interpreted_procs_outbound_network_activity\u0026gt; Interpreted procs outbound network activity \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Any outbound network activity performed by any interpreted program (perl, python, ruby, etc.). While it offers broad coverage and behavioral insights, operationalizing it effectively requires significant time and might result in a moderate level of noise. Suggesting customizing this rule to be more specific. For example, you could set it up to alert only for important namespaces after studying their usual behavior. Condition:\noutbound and interpreted_procs Output:\nInterpreted program performed outgoing network connection | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_exfiltration\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0011\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Interpreted_procs_outbound_network_activity /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Unexpected_K8s_NodePort_Connection\u0026gt; Unexpected K8s NodePort Connection \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect attempts to utilize K8s NodePorts from a container. K8s NodePorts are accessible on the eth0 interface of each node, and they facilitate external traffic into a Kubernetes cluster. Attackers could misuse them for unauthorized access. The rule uses default port ranges, but check for custom ranges and make necessary adjustments. Also, consider tuning this rule as needed. Condition:\ninbound_outbound and container and fd.sport \u0026gt;= 30000 and fd.sport \u0026lt;= 32767 and not nodeport_containers Output:\nUnexpected K8s NodePort Connection | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; k8s\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1205.001\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; NIST_800-53_AC-6\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Unexpected_K8s_NodePort_Connection /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Create_Hidden_Files_or_Directories\u0026gt; Create Hidden Files or Directories \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detecting hidden files or directories creation can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. Condition:\n((modify and evt.arg.newpath contains \u0026quot;/.\u0026quot;) or (mkdir and evt.arg.path contains \u0026quot;/.\u0026quot;) or (open_write and evt.arg.flags contains \u0026quot;O_CREAT\u0026quot; and fd.name contains \u0026quot;/.\u0026quot; and not fd.name pmatch (exclude_hidden_directories))) and not user_known_create_hidden_file_activities and not exe_running_docker_save Output:\nHidden file or directory created | file=%fd.name newpath=%evt.arg.newpath evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_defense_evasion\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1564.001\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Create_Hidden_Files_or_Directories /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Detect_outbound_connections_to_common_miner_pool_ports\u0026gt; Detect outbound connections to common miner pool ports \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority critical chip small\u0026quot;\u0026gt;CRITICAL\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Miners usually connect to miner pools using standard ports, and this rule flags such activity. Important: Falco currently sends DNS requests to resolve miner pool domains, which could trigger other alerts. Prior to enabling this rule, it\u0026amp;#39;s advised to ensure whether this is acceptable for your environment. This rule is specifically disabled for that reason. Condition:\nnet_miner_pool and not trusted_images_query_miner_domain_dns Output:\nOutbound connection to IP/Port flagged by https://cryptoioc.ch | ip=%fd.rip connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: CRITICAL Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_impact\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1496\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Detect_outbound_connections_to_common_miner_pool_ports /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Detect_crypto_miners_using_the_Stratum_protocol\u0026gt; Detect crypto miners using the Stratum protocol \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority critical chip small\u0026quot;\u0026gt;CRITICAL\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Miners commonly specify the mining pool to connect to using a URI that starts with \u0026amp;#34;stratum\u0026amp;#43;tcp\u0026amp;#34;. However, this rule is highly specific to this technique, and matching command-line arguments can generally be bypassed quite easily. Condition:\nspawned_process and (proc.cmdline contains \u0026quot;stratum+tcp\u0026quot; or proc.cmdline contains \u0026quot;stratum2+tcp\u0026quot; or proc.cmdline contains \u0026quot;stratum+ssl\u0026quot; or proc.cmdline contains \u0026quot;stratum2+ssl\u0026quot;) Output:\nPossible miner running | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: sandbox Priority: CRITICAL Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_impact\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1496\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Detect_crypto_miners_using_the_Stratum_protocol /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Kubernetes_Client_Tool_Launched_in_Container\u0026gt; Kubernetes Client Tool Launched in Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect the execution of a Kubernetes client tool (like docker, kubectl, crictl) within a container, which is typically not expected behavior. Although this rule targets container workloads, monitoring the use of tools like crictl on the host over interactive access could also be valuable for broader auditing objectives. Condition:\nspawned_process and container and not user_known_k8s_client_container_parens and proc.name in (k8s_client_binaries) Output:\nKubernetes Client Tool Launched in Container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: sandbox Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1610\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Kubernetes_Client_Tool_Launched_in_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Container_Drift_Detected_(chmod)\u0026gt; Container Drift Detected (chmod) \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect new executables created within a container as a result of chmod. While this detection can generate significant noise, chmod usage is frequently linked to dropping and executing malicious implants. The newer rule \u0026amp;#34;Drop and execute new binary in container\u0026amp;#34; provides more precise detection of this TTP using unambiguous kernel signals. It is recommended to use the new rule. However, this rule might be more relevant for auditing if applicable in your environment, such as when chmod is used on files within the /tmp folder. Condition:\nchmod and container and evt.rawres\u0026gt;=0 and ((evt.arg.mode contains \u0026quot;S_IXUSR\u0026quot;) or (evt.arg.mode contains \u0026quot;S_IXGRP\u0026quot;) or (evt.arg.mode contains \u0026quot;S_IXOTH\u0026quot;)) and not runc_writing_exec_fifo and not runc_writing_var_lib_docker and not user_known_container_drift_activities Output:\nDrift detected (chmod), new executable created in a container | filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Container_Drift_Detected_%28chmod%29 /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Container_Drift_Detected_(open\u0026amp;#43;create)\u0026gt; Container Drift Detected (open\u0026amp;#43;create) \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority error chip small\u0026quot;\u0026gt;ERROR\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect new executables created within a container as a result of open\u0026amp;#43;create. The newer rule \u0026amp;#34;Drop and execute new binary in container\u0026amp;#34; provides more precise detection of this TTP using unambiguous kernel signals. It is recommended to use the new rule. Condition:\nevt.type in (open,openat,openat2,creat) and evt.rawres\u0026gt;=0 and evt.is_open_exec=true and container and not runc_writing_exec_fifo and not runc_writing_var_lib_docker and not user_known_container_drift_activities Output:\nDrift detected (open+create), new executable created in a container | filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: ERROR Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Container_Drift_Detected_%28open%2bcreate%29 /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Container_Run_as_Root_User\u0026gt; Container Run as Root User \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority info chip small\u0026quot;\u0026gt;INFO\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Container detected running as the root user. This should be taken into account especially when policies disallow containers from running with root user privileges. Note that a root user in containers doesn\u0026amp;#39;t inherently possess extensive power, as modern container environments define privileges through Linux capabilities. To learn more, check out the rule \u0026amp;#34;Launch Privileged Container\u0026amp;#34;. Condition:\nspawned_process and container and proc.vpid=1 and user.uid=0 and not user_known_run_as_root_container Output:\nContainer launched with root user privilege | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: sandbox Priority: INFO Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; users\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1610\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Container_Run_as_Root_User /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Sudo_Potential_Privilege_Escalation\u0026gt; Sudo Potential Privilege Escalation \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority critical chip small\u0026quot;\u0026gt;CRITICAL\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Affecting sudo (\u0026amp;lt;= 1.9.5p2), there\u0026amp;#39;s a privilege escalation vulnerability. By executing sudo using the sudoedit -s or sudoedit -i command with a command-line argument that ends with a single backslash character, an unprivileged user can potentially escalate privileges to root. This rule is highly specific and might be bypassed due to potential issues with string matching on command line arguments. Condition:\nspawned_process and user.uid != 0 and (proc.name=sudoedit or proc.name = sudo) and (proc.args contains -s or proc.args contains -i or proc.args contains --login) and (proc.args contains \u0026quot;\\ \u0026quot; or proc.args endswith ) Output:\nDetect Sudo Privilege Escalation Exploit (CVE-2021-3156) | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: sandbox Priority: CRITICAL Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; users\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1548.003\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Sudo_Potential_Privilege_Escalation /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Unprivileged_Delegation_of_Page_Faults_Handling_to_a_Userspace_Process\u0026gt; Unprivileged Delegation of Page Faults Handling to a Userspace Process \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority critical chip small\u0026quot;\u0026gt;CRITICAL\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect a successful unprivileged userfaultfd syscall, which could serve as an attack primitive for exploiting other vulnerabilities. To fine-tune this rule, consider using the template list \u0026amp;#34;user_known_userfaultfd_processes\u0026amp;#34;. Condition:\nevt.type = userfaultfd and user.uid != 0 and (evt.rawres \u0026gt;= 0 or evt.res != -1) and not proc.name in (user_known_userfaultfd_processes) Output:\nAn userfaultfd syscall was successfully executed by an unprivileged user | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: CRITICAL Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_defense_evasion\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0005\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Unprivileged_Delegation_of_Page_Faults_Handling_to_a_Userspace_Process /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Polkit_Local_Privilege_Escalation_Vulnerability_(CVE-2021-4034)\u0026gt; Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034) \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority critical chip small\u0026quot;\u0026gt;CRITICAL\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;This rule detects attempts to exploit a privilege escalation vulnerability in Polkit\u0026amp;#39;s pkexec. Through the execution of specially crafted code, a local user can exploit this weakness to attain root privileges on a compromised system. This rule is highly specific in its scope. Condition:\nspawned_process and user.uid != 0 and proc.name=pkexec and proc.args = '' Output:\nDetect Polkit pkexec Local Privilege Escalation Exploit (CVE-2021-4034) | args=%proc.args evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: sandbox Priority: CRITICAL Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; users\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0004\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Polkit_Local_Privilege_Escalation_Vulnerability_%28CVE-2021-4034%29 /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Java_Process_Class_File_Download\u0026gt; Java Process Class File Download \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority critical chip small\u0026quot;\u0026gt;CRITICAL\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detecting a Java process downloading a class file which could indicate a successful exploit of the log4shell Log4j vulnerability (CVE-2021-44228). This rule is highly specific in its scope. Condition:\njava_network_read and evt.buffer bcontains cafebabe Output:\nJava process class file download | server_ip=%fd.sip server_port=%fd.sport connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: CRITICAL Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_initial_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1190\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Java_Process_Class_File_Download /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Modify_Container_Entrypoint\u0026gt; Modify Container Entrypoint \u0026lt;span class=\u0026quot;status disabled chip small\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;This rule detect an attempt to write on container entrypoint symlink (/proc/self/exe). Possible CVE-2019-5736 Container Breakout exploitation attempt. This rule has a more narrow scope. Condition:\nopen_write and container and (fd.name=/proc/self/exe or fd.name startswith /proc/self/fd/) and not docker_procs and not proc.cmdline = \u0026quot;runc:[1:CHILD] init\u0026quot; Output:\nDetect Potential Container Breakout Exploit (CVE-2019-5736) | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: sandbox Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_initial_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1611\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status disabled chip\u0026quot;\u0026gt;disabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Modify_Container_Entrypoint /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Decoding_Payload_in_Container\u0026gt; Decoding Payload in Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority info chip small\u0026quot;\u0026gt;INFO\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect any use of {base64} decoding in a container. Legitimate applications may decode encoded payloads. The template list known_decode_payload_containers can be used for simple tuning and customization, or you can adopt custom, more refined tuning. Less sophisticated adversaries may {base64}-decode their payloads not only to obfuscate them, but also to ensure that the payload remains intact when the application processes it. Note that injecting commands into an application\u0026amp;#39;s input often results in the application processing passed strings like \u0026amp;#34;sh -c\u0026amp;#34;. In these cases, you may be lucky and the encoded blob will also be logged. Otherwise, all you will see is the {base64} decoding command, as the encoded blob was already interpreted by the shell. Condition:\nspawned_process and container and base64_decoding and not container.image.repository in (known_decode_payload_containers) Output:\nDecoding Payload in Container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: sandbox Priority: INFO Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_command_and_control\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1132\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Decoding_Payload_in_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Basic_Interactive_Reconnaissance\u0026gt; Basic Interactive Reconnaissance \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;This rule detects basic interactive reconnaissance commands that are typically run by unsophisticated attackers or used in internal Red Team exercises. Interactive is defined as a terminal being present (proc.tty != 0). This could be any form of reverse shell or usage of kubectl exec or ssh etc. In addition, filtering for the process being the process group leader indicates that the command was \u0026amp;#34;directly\u0026amp;#34; typed into the terminal and not run as a result of a script. This rule is a basic auditing or template rule. You can expand the list of reconnaissance commands, such as by adding \u0026amp;#34;ls\u0026amp;#34;. Common anti-patterns are SRE activity or debugging, but it is still worth capturing this generically. Typically, you would expect other rules to fire as well in relation to this activity. Condition:\nspawned_process and recon_binaries_procs and proc.tty != 0 and proc.is_vpgid_leader=true Output:\nBasic Interactive Reconnaissance | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: sandbox Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_reconnaissance\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0043\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Basic_Interactive_Reconnaissance /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Netcat/Socat_Remote_Code_Execution_on_Host\u0026gt; Netcat/Socat Remote Code Execution on Host \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity sandbox chip small\u0026quot;\u0026gt;sandbox\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Netcat/Socat Program runs on host that allows remote code execution and may be utilized as a part of a variety of reverse shell payload https://github.com/swisskyrepo/PayloadsAllTheThings/. These programs are of higher relevance as they are commonly installed on UNIX-like operating systems. Condition:\nspawned_process and not container and ((proc.name = \u0026quot;nc\u0026quot; and (proc.cmdline contains \u0026quot;-e\u0026quot; or proc.cmdline contains \u0026quot;-c\u0026quot;)) or (proc.name = \u0026quot;ncat\u0026quot; and (proc.args contains \u0026quot;--sh-exec\u0026quot; or proc.args contains \u0026quot;--exec\u0026quot; or proc.args contains \u0026quot;-e \u0026quot; or proc.args contains \u0026quot;-c \u0026quot; or proc.args contains \u0026quot;--lua-exec\u0026quot;)) or (proc.name = 'socat' and (proc.args contains \u0026quot;EXEC\u0026quot; or proc.args contains \u0026quot;SYSTEM\u0026quot;))) Output:\nNetcat/Socat runs on host that allows remote code execution | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: sandbox Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_sandbox\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Netcat%2fSocat_Remote_Code_Execution_on_Host /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Directory_traversal_monitored_file_read\u0026gt; Directory traversal monitored file read \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Web applications can be vulnerable to directory traversal attacks that allow accessing files outside of the web app\u0026amp;#39;s root directory (e.g. Arbitrary File Read bugs). System directories like /etc are typically accessed via absolute paths. Access patterns outside of this (here path traversal) can be regarded as suspicious. This rule includes failed file open attempts. Condition:\n(open_read or open_file_failed) and (etc_dir or user_ssh_directory or fd.name startswith /root/.ssh or fd.name contains \u0026quot;id_rsa\u0026quot;) and directory_traversal and not proc.pname in (shell_binaries) Output:\nRead monitored file via directory traversal | file=%fd.name fileraw=%fd.nameraw gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_credential_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1555\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Directory_traversal_monitored_file_read /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Read_sensitive_file_trusted_after_startup\u0026gt; Read sensitive file trusted after startup \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;An attempt to read any sensitive file (e.g. files containing user/password/authentication information) by a trusted program after startup. Trusted programs might read these files at startup to load initial state, but not afterwards. Can be customized as needed. In modern containerized cloud infrastructures, accessing traditional Linux sensitive files might be less relevant, yet it remains valuable for baseline detections. While we provide additional rules for SSH or cloud vendor-specific credentials, you can significantly enhance your security program by crafting custom rules for critical application credentials unique to your environment. Condition:\nopen_read and sensitive_files and server_procs and not proc_is_new and proc.name!=\u0026quot;sshd\u0026quot; and not user_known_read_sensitive_files_activities Output:\nSensitive file opened for reading by trusted program after startup | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_credential_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1555\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Read_sensitive_file_trusted_after_startup /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Read_sensitive_file_untrusted\u0026gt; Read sensitive file untrusted \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;An attempt to read any sensitive file (e.g. files containing user/password/authentication information). Exceptions are made for known trusted programs. Can be customized as needed. In modern containerized cloud infrastructures, accessing traditional Linux sensitive files might be less relevant, yet it remains valuable for baseline detections. While we provide additional rules for SSH or cloud vendor-specific credentials, you can significantly enhance your security program by crafting custom rules for critical application credentials unique to your environment. Condition:\nopen_read and sensitive_files and proc_name_exists and not proc.name in (user_mgmt_binaries, userexec_binaries, package_mgmt_binaries, cron_binaries, read_sensitive_file_binaries, shell_binaries, hids_binaries, vpn_binaries, mail_config_binaries, nomachine_binaries, sshkit_script_binaries, in.proftpd, mandb, salt-call, salt-minion, postgres_mgmt_binaries, google_oslogin_ ) and not cmp_cp_by_passwd and not ansible_running_python and not run_by_qualys and not run_by_chef and not run_by_google_accounts_daemon and not user_read_sensitive_file_conditions and not mandb_postinst and not perl_running_plesk and not perl_running_updmap and not veritas_driver_script and not perl_running_centrifydc and not runuser_reading_pam and not linux_bench_reading_etc_shadow and not user_known_read_sensitive_files_activities and not user_read_sensitive_file_containers Output:\nSensitive file opened for reading by non-trusted program | file=%fd.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_credential_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1555\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Read_sensitive_file_untrusted /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Run_shell_untrusted\u0026gt; Run shell untrusted \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;An attempt to spawn a shell below a non-shell application. The non-shell applications that are monitored are defined in the protected_shell_spawner macro, with protected_shell_spawning_binaries being the list you can easily customize. For Java parent processes, please note that Java often has a custom process name. Therefore, rely more on proc.exe to define Java applications. This rule can be noisier, as you can see in the exhaustive existing tuning. However, given it is very behavior-driven and broad, it is universally relevant to catch general Remote Code Execution (RCE). Allocate time to tune this rule for your use cases and reduce noise. Tuning suggestions include looking at the duration of the parent process (proc.ppid.duration) to define your long-running app processes. Checking for newer fields such as proc.vpgid.name and proc.vpgid.exe instead of the direct parent process being a non-shell application could make the rule more robust. Condition:\nspawned_process and shell_procs and proc.pname exists and protected_shell_spawner and not proc.pname in (shell_binaries, gitlab_binaries, cron_binaries, user_known_shell_spawn_binaries, needrestart_binaries, mesos_shell_binaries, erl_child_setup, exechealthz, PM2, PassengerWatchd, c_rehash, svlogd, logrotate, hhvm, serf, lb-controller, nvidia-installe, runsv, statsite, erlexec, calico-node, \u0026quot;puma reactor\u0026quot;) and not proc.cmdline in (known_shell_spawn_cmdlines) and not proc.aname in (unicorn_launche) and not consul_running_net_scripts and not consul_running_alert_checks and not nginx_starting_nginx and not nginx_running_aws_s3_cp and not run_by_package_mgmt_binaries and not serf_script and not check_process_status and not run_by_foreman and not python_mesos_marathon_scripting and not splunk_running_forwarder and not postgres_running_wal_e and not redis_running_prepost_scripts and not rabbitmq_running_scripts and not rabbitmqctl_running_scripts and not run_by_appdynamics and not user_shell_container_exclusions Output:\nShell spawned by untrusted binary | parent_exe=%proc.pexe parent_exepath=%proc.pexepath pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] aname[4]=%proc.aname[4] aname[5]=%proc.aname[5] aname[6]=%proc.aname[6] aname[7]=%proc.aname[7] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; shell\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059.004\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Run_shell_untrusted /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=System_user_interactive\u0026gt; System user interactive \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority info chip small\u0026quot;\u0026gt;INFO\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;System (e.g. non-login) users spawning new processes. Can add custom service users (e.g. apache or mysqld). \u0026amp;#39;Interactive\u0026amp;#39; is defined as new processes as descendants of an ssh session or login process. Consider further tuning by only looking at processes in a terminal / tty (proc.tty != 0). A newer field proc.is_vpgid_leader could be of help to distinguish if the process was \u0026amp;#34;directly\u0026amp;#34; executed, for instance, in a tty, or executed as a descendant process in the same process group, which, for example, is the case when subprocesses are spawned from a script. Consider this rule as a great template rule to monitor interactive accesses to your systems more broadly. However, such a custom rule would be unique to your environment. The rule \u0026amp;#34;Terminal shell in container\u0026amp;#34; that fires when using \u0026amp;#34;kubectl exec\u0026amp;#34; is more Kubernetes relevant, whereas this one could be more interesting for the underlying host. Condition:\nspawned_process and system_users and interactive and not user_known_system_user_login Output:\nSystem user ran an interactive command | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: INFO Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; users\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; NIST_800-53_AC-2\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#System_user_interactive /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Terminal_shell_in_container\u0026gt; Terminal shell in container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;A shell was used as the entrypoint/exec point into a container with an attached terminal. Parent process may have legitimately already exited and be null (read container_entrypoint macro). Common when using \u0026amp;#34;kubectl exec\u0026amp;#34; in Kubernetes. Correlate with k8saudit exec logs if possible to find user or serviceaccount token used (fuzzy correlation by namespace and pod name). Rather than considering it a standalone rule, it may be best used as generic auditing rule while examining other triggered rules in this container/tty. Condition:\nspawned_process and container and shell_procs and proc.tty != 0 and container_entrypoint and not user_expected_terminal_shell_in_container_conditions Output:\nA shell was spawned in a container with an attached terminal | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; shell\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Terminal_shell_in_container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Contact_K8S_API_Server_From_Container\u0026gt; Contact K8S API Server From Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect attempts to communicate with the K8S API Server from a container by non-profiled users. Kubernetes APIs play a pivotal role in configuring the cluster management lifecycle. Detecting potential unauthorized access to the API server is of utmost importance. Audit your complete infrastructure and pinpoint any potential machines from which the API server might be accessible based on your network layout. If Falco can\u0026amp;#39;t operate on all these machines, consider analyzing the Kubernetes audit logs (typically drained from control nodes, and Falco offers a k8saudit plugin) as an additional data source for detections within the control plane. Condition:\nevt.type=connect and (fd.typechar=4 or fd.typechar=6) and container and k8s_api_server and not k8s_containers and not user_known_contact_k8s_api_server_activities Output:\nUnexpected connection to K8s API Server from container | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; k8s\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_discovery\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1565\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Contact_K8S_API_Server_From_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Netcat_Remote_Code_Execution_in_Container\u0026gt; Netcat Remote Code Execution in Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Netcat Program runs inside container that allows remote code execution and may be utilized as a part of a variety of reverse shell payload https://github.com/swisskyrepo/PayloadsAllTheThings/. These programs are of higher relevance as they are commonly installed on UNIX-like operating systems. Can fire in combination with the \u0026amp;#34;Redirect STDOUT/STDIN to Network Connection in Container\u0026amp;#34; rule as it utilizes a different evt.type. Condition:\nspawned_process and container and ((proc.name = \u0026quot;nc\u0026quot; and (proc.cmdline contains \u0026quot; -e\u0026quot; or proc.cmdline contains \u0026quot; -c\u0026quot;)) or (proc.name = \u0026quot;ncat\u0026quot; and (proc.args contains \u0026quot;--sh-exec\u0026quot; or proc.args contains \u0026quot;--exec\u0026quot; or proc.args contains \u0026quot;-e \u0026quot; or proc.args contains \u0026quot;-c \u0026quot; or proc.args contains \u0026quot;--lua-exec\u0026quot;)) ) Output:\nNetcat runs inside container that allows remote code execution | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Netcat_Remote_Code_Execution_in_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Search_Private_Keys_or_Passwords\u0026gt; Search Private Keys or Passwords \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect attempts to search for private keys or passwords using the grep or find command. This is often seen with unsophisticated attackers, as there are many ways to access files using bash built-ins that could go unnoticed. Regardless, this serves as a solid baseline detection that can be tailored to cover these gaps while maintaining an acceptable noise level. Condition:\nspawned_process and ((grep_commands and private_key_or_password) or (proc.name = \u0026quot;find\u0026quot; and (proc.args contains \u0026quot;id_rsa\u0026quot; or proc.args contains \u0026quot;id_dsa\u0026quot; or proc.args contains \u0026quot;id_ed25519\u0026quot; or proc.args contains \u0026quot;id_ecdsa\u0026quot; ) )) Output:\nGrep private keys or passwords activities found | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_credential_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1552.001\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Search_Private_Keys_or_Passwords /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Clear_Log_Activities\u0026gt; Clear Log Activities \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect clearing of critical access log files, typically done to erase evidence that could be attributed to an adversary\u0026amp;#39;s actions. To effectively customize and operationalize this detection, check for potentially missing log file destinations relevant to your environment, and adjust the profiled containers you wish not to be alerted on. Condition:\nopen_write and access_log_files and evt.arg.flags contains \u0026quot;O_TRUNC\u0026quot; and not containerd_activities and not trusted_logging_images and not allowed_clear_log_files Output:\nLog files were tampered | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_defense_evasion\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1070\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; NIST_800-53_AU-10\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Clear_Log_Activities /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Remove_Bulk_Data_from_Disk\u0026gt; Remove Bulk Data from Disk \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect a process running to clear bulk data from disk with the intention to destroy data, possibly interrupting availability to systems. Profile your environment and use user_known_remove_data_activities to tune this rule. Condition:\nspawned_process and clear_data_procs and not user_known_remove_data_activities Output:\nBulk data has been removed from disk | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_impact\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1485\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Remove_Bulk_Data_from_Disk /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Create_Symlink_Over_Sensitive_Files\u0026gt; Create Symlink Over Sensitive Files \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect symlinks created over a curated list of sensitive files or subdirectories under /etc/ or root directories. Can be customized as needed. Refer to further and equivalent guidance within the rule \u0026amp;#34;Read sensitive file untrusted\u0026amp;#34;. Condition:\ncreate_symlink and (evt.arg.target in (sensitive_file_names) or evt.arg.target in (sensitive_directory_names)) Output:\nSymlinks created over sensitive files | target=%evt.arg.target linkpath=%evt.arg.linkpath evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_credential_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1555\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Create_Symlink_Over_Sensitive_Files /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Create_Hardlink_Over_Sensitive_Files\u0026gt; Create Hardlink Over Sensitive Files \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect hardlink created over a curated list of sensitive files or subdirectories under /etc/ or root directories. Can be customized as needed. Refer to further and equivalent guidance within the rule \u0026amp;#34;Read sensitive file untrusted\u0026amp;#34;. Condition:\ncreate_hardlink and (evt.arg.oldpath in (sensitive_file_names)) Output:\nHardlinks created over sensitive files | target=%evt.arg.oldpath linkpath=%evt.arg.newpath evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; filesystem\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_credential_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1555\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Create_Hardlink_Over_Sensitive_Files /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Packet_socket_created_in_container\u0026gt; Packet socket created in container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect new packet socket at the device driver (OSI Layer 2) level in a container. Packet socket could be used for ARP Spoofing and privilege escalation (CVE-2020-14386) by an attacker. Noise can be reduced by using the user_known_packet_socket_binaries template list. Condition:\nevt.type=socket and container and evt.arg.domain contains AF_PACKET and not proc.name in (user_known_packet_socket_binaries) Output:\nPacket socket was created in a container | socket_info=%evt.args connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_credential_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1557.002\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Packet_socket_created_in_container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Redirect_STDOUT/STDIN_to_Network_Connection_in_Container\u0026gt; Redirect STDOUT/STDIN to Network Connection in Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect redirection of stdout/stdin to a network connection within a container, achieved by utilizing a variant of the dup syscall (potential reverse shell or remote code execution https://github.com/swisskyrepo/PayloadsAllTheThings/). This detection is behavior-based and may generate noise in the system, and can be adjusted using the user_known_stand_streams_redirect_activities template macro. Tuning can be performed similarly to existing detections based on process lineage or container images, and/or it can be limited to interactive tty (tty != 0). Condition:\ndup and container and evt.rawres in (0, 1, 2) and fd.type in (\u0026quot;ipv4\u0026quot;, \u0026quot;ipv6\u0026quot;) and not user_known_stand_streams_redirect_activities Output:\nRedirect stdout/stdin to network connection | gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] fd.sip=%fd.sip connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Redirect_STDOUT%2fSTDIN_to_Network_Connection_in_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Linux_Kernel_Module_Injection_Detected\u0026gt; Linux Kernel Module Injection Detected \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Inject Linux Kernel Modules from containers using insmod or modprobe with init_module and finit_module syscalls, given the precondition of sys_module effective capabilities. Profile the environment and consider allowed_container_images_loading_kernel_module to reduce noise and account for legitimate cases. Condition:\nkernel_module_load and container and thread.cap_effective icontains sys_module and not container.image.repository in (allowed_container_images_loading_kernel_module) Output:\nLinux Kernel Module injection from container | parent_exepath=%proc.pexepath gparent=%proc.aname[2] gexepath=%proc.aexepath[2] module=%proc.args res=%evt.res evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0003\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Linux_Kernel_Module_Injection_Detected /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Debugfs_Launched_in_Privileged_Container\u0026gt; Debugfs Launched in Privileged Container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect file system debugger debugfs launched inside a privileged container which might lead to container escape. This rule has a more narrow scope. Condition:\nspawned_process and container and container.privileged=true and proc.name=debugfs Output:\nDebugfs launched started in a privileged container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; cis\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1611\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Debugfs_Launched_in_Privileged_Container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Detect_release_agent_File_Container_Escapes\u0026gt; Detect release_agent File Container Escapes \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority critical chip small\u0026quot;\u0026gt;CRITICAL\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect an attempt to exploit a container escape using release_agent file. By running a container with certains capabilities, a privileged user can modify release_agent file and escape from the container. Condition:\nopen_write and container and fd.name endswith release_agent and (user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and thread.cap_effective contains CAP_SYS_ADMIN Output:\nDetect an attempt to exploit a container escape using release_agent file | file=%fd.name cap_effective=%thread.cap_effective evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: CRITICAL Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1611\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Detect_release_agent_File_Container_Escapes /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=PTRACE_attached_to_process\u0026gt; PTRACE attached to process \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect an attempt to inject potentially malicious code into a process using PTRACE in order to evade process-based defenses or elevate privileges. Common anti-patterns are debuggers. Additionally, profiling your environment via the known_ptrace_procs template macro can reduce noise. A successful ptrace syscall generates multiple logs at once. Condition:\nptrace_attach_or_injection and proc_name_exists and not known_ptrace_procs Output:\nDetected ptrace PTRACE_ATTACH attempt | proc_pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_privilege_escalation\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1055.008\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#PTRACE_attached_to_process /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=PTRACE_anti-debug_attempt\u0026gt; PTRACE anti-debug attempt \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect usage of the PTRACE system call with the PTRACE_TRACEME argument, indicating a program actively attempting to avoid debuggers attaching to the process. This behavior is typically indicative of malware activity. Read more about PTRACE in the \u0026amp;#34;PTRACE attached to process\u0026amp;#34; rule. Condition:\nevt.type=ptrace and evt.arg.request contains PTRACE_TRACEME and proc_name_exists Output:\nDetected potential PTRACE_TRACEME anti-debug attempt | proc_pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_defense_evasion\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1622\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#PTRACE_anti-debug_attempt /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Find_AWS_Credentials\u0026gt; Find AWS Credentials \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect attempts to search for private keys or passwords using the grep or find command, particularly targeting standard AWS credential locations. This is often seen with unsophisticated attackers, as there are many ways to access files using bash built-ins that could go unnoticed. Regardless, this serves as a solid baseline detection that can be tailored to cover these gaps while maintaining an acceptable noise level. This rule complements the rule \u0026amp;#34;Search Private Keys or Passwords\u0026amp;#34;. Condition:\nspawned_process and ((grep_commands and private_aws_credentials) or (proc.name = \u0026quot;find\u0026quot; and proc.args endswith \u0026quot;.aws/credentials\u0026quot;)) Output:\nDetected AWS credentials search activity | proc_pcmdline=%proc.pcmdline proc_cwd=%proc.cwd group_gid=%group.gid group_name=%group.name user_loginname=%user.loginname evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; aws\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_credential_access\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1552\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Find_AWS_Credentials /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Execution_from_/dev/shm\u0026gt; Execution from /dev/shm \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority warning chip small\u0026quot;\u0026gt;WARNING\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;This rule detects file execution in the /dev/shm directory, a tactic often used by threat actors to store their readable, writable, and occasionally executable files. /dev/shm acts as a link to the host or other containers, creating vulnerabilities for their compromise as well. Notably, /dev/shm remains unchanged even after a container restart. Consider this rule alongside the newer \u0026amp;#34;Drop and execute new binary in container\u0026amp;#34; rule. Condition:\nspawned_process and (proc.exe startswith \u0026quot;/dev/shm/\u0026quot; or (proc.cwd startswith \u0026quot;/dev/shm/\u0026quot; and proc.exe startswith \u0026quot;./\u0026quot; ) or (shell_procs and proc.args startswith \u0026quot;-c /dev/shm\u0026quot;) or (shell_procs and proc.args startswith \u0026quot;-i /dev/shm\u0026quot;) or (shell_procs and proc.args startswith \u0026quot;/dev/shm\u0026quot;) or (proc.cwd startswith \u0026quot;/dev/shm/\u0026quot; and proc.args startswith \u0026quot;./\u0026quot; )) and not container.image.repository in (falco_privileged_images, trusted_images) Output:\nFile execution detected from /dev/shm | evt_res=%evt.res file=%fd.name proc_cwd=%proc.cwd proc_pcmdline=%proc.pcmdline user_loginname=%user.loginname group_gid=%group.gid group_name=%group.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: WARNING Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059.004\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Execution_from_%2fdev%2fshm /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Drop_and_execute_new_binary_in_container\u0026gt; Drop and execute new binary in container \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority critical chip small\u0026quot;\u0026gt;CRITICAL\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect if an executable not belonging to the base image of a container is being executed. The drop and execute pattern can be observed very often after an attacker gained an initial foothold. is_exe_upper_layer filter field only applies for container runtimes that use overlayfs as union mount filesystem. Adopters can utilize the provided template list known_drop_and_execute_containers containing allowed container images known to execute binaries not included in their base image. Alternatively, you could exclude non-production namespaces in Kubernetes settings by adjusting the rule further. This helps reduce noise by applying application and environment-specific knowledge to this rule. Common anti-patterns include administrators or SREs performing ad-hoc debugging. Condition:\nspawned_process and container and proc.is_exe_upper_layer=true and not container.image.repository in (known_drop_and_execute_containers) and not known_drop_and_execute_activities Output:\nExecuting binary not part of base image | proc_exe=%proc.exe proc_sname=%proc.sname gparent=%proc.aname[2] proc_exe_ino_ctime=%proc.exe_ino.ctime proc_exe_ino_mtime=%proc.exe_ino.mtime proc_exe_ino_ctime_duration_proc_start=%proc.exe_ino.ctime_duration_proc_start proc_cwd=%proc.cwd container_start_ts=%container.start_ts evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: CRITICAL Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_persistence\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; TA0003\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; PCI_DSS_11.5.1\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Drop_and_execute_new_binary_in_container /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Disallowed_SSH_Connection_Non_Standard_Port\u0026gt; Disallowed SSH Connection Non Standard Port \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority notice chip small\u0026quot;\u0026gt;NOTICE\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect any new outbound SSH connection from the host or container using a non-standard port. This rule holds the potential to detect a family of reverse shells that cause the victim machine to connect back out over SSH, with STDIN piped from the SSH connection to a shell\u0026amp;#39;s STDIN, and STDOUT of the shell piped back over SSH. Such an attack can be launched against any app that is vulnerable to command injection. The upstream rule only covers a limited selection of non-standard ports. We suggest adding more ports, potentially incorporating ranges based on your environment\u0026amp;#39;s knowledge and custom SSH port configurations. This rule can complement the \u0026amp;#34;Redirect STDOUT/STDIN to Network Connection in Container\u0026amp;#34; or \u0026amp;#34;Disallowed SSH Connection\u0026amp;#34; rule. Condition:\noutbound and proc.exe endswith ssh and fd.l4proto=tcp and ssh_non_standard_ports_network Output:\nDisallowed SSH Connection | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty Maturity: stable Priority: NOTICE Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; network\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_execution\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1059\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Disallowed_SSH_Connection_Non_Standard_Port /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;button type=\u0026quot;button\u0026quot; class=\u0026quot;collapsible\u0026quot; id=Fileless_execution_via_memfd_create\u0026gt; Fileless execution via memfd_create \u0026lt;span class=\u0026quot;status enabled chip small\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;priority critical chip small\u0026quot;\u0026gt;CRITICAL\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;maturity stable chip small\u0026quot;\u0026gt;stable\u0026lt;/span\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;div class=\u0026quot;rule\u0026quot;\u0026gt; \u0026lt;div class=\u0026quot;descriptionDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Description:\u0026lt;/span\u0026gt;\u0026lt;/br\u0026gt; \u0026lt;pre\u0026gt;\u0026lt;code class=\u0026quot;condition\u0026quot; style=\u0026quot;white-space: pre-wrap;\u0026quot;\u0026gt;Detect if a binary is executed from memory using the memfd_create technique. This is a well-known defense evasion technique for executing malware on a victim machine without storing the payload on disk and to avoid leaving traces about what has been executed. Adopters can whitelist processes that may use fileless execution for benign purposes by adding items to the list known_memfd_execution_processes. Condition:\nspawned_process and proc.is_exe_from_memfd=true and not known_memfd_execution_processes Output:\nFileless execution via memfd_create | container_start_ts=%container.start_ts proc_cwd=%proc.cwd evt_res=%evt.res proc_sname=%proc.sname gparent=%proc.aname[2] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags Maturity: stable Priority: CRITICAL Tags:\n\u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; maturity_stable\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; host\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; container\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; process\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; mitre_defense_evasion\u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;chip\u0026quot;\u0026gt; T1620\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div class=\u0026quot;statusDiv\u0026quot;\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Status: \u0026lt;/span\u0026gt; \u0026lt;span class=\u0026quot;status enabled chip\u0026quot;\u0026gt;enabled\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; \u0026lt;span class=\u0026quot;field\u0026quot;\u0026gt;Link: \u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;\u0026lt;a href=#Fileless_execution_via_memfd_create /\u0026gt;\u0026lt;i class=\u0026quot;fa fa-link\u0026quot; style=\u0026quot;padding-bottom: 15px;\u0026quot;\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;/a\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; ","summary":"","tags":null,"title":"Default Rules","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/rules/default-rules/"},{"category":"docs","content":"To write a custom rule for Falco from scratch, it is essential to understand the conditions that need to be met for Falco to trigger an alert. However, this task is complex as it requires considering the potential false positives and negatives arising from the rule.\nRules Placement When adding a new rule to Falco, the first step is determining its placement. For instance, when loading syscall rules, Falco groups them per system call (evt.type) for faster matching and processes them later in sequential order, ensuring that two rules are not triggered simultaneously for the same evt.type field value. Consequently, more general rules should be positioned at the end of the rule set, while more specific rules should be placed at the beginning. This arrangement prevents general rules from capturing events that more specific rules should handle.\nIt's worth noting that Falco loads a set of predefined rules by default, followed by any custom rules located in the /etc/falco/rules.d directory. This configuration is specified in the /etc/falco/falco.yaml file, under the rules_files key, as follows:\nrules_files: - /etc/falco/falco_rules.yaml - /etc/falco/falco_rules.local.yaml - /etc/falco/rules.d It can nevertheless be adjusted to prioritize the rules in the rules.d directory, include different rule files or even add new directories. The customization options are flexible.\nConsidering this, it's important to remember that the default rules file includes reusable lists and macros that may help to create new rules. Therefore, you should carefully decide whether you want to delay the processing of those files or turn off a general rule that captures events intended for your custom rule. Alternatively, you can customize an existing rule within the rules.d directory by either rewriting the entire rule or using the \u0026quot;append\u0026quot; key to modify it.\nIf you are deploying Falco on a Kubernetes cluster, you will likely use Helm for the installation. In this scenario, instead of placing custom rules files directly in the /etc/falco/rules.d directory, you can add them to the values.yaml file provided to the helm command.\nLocate the line customRules: {} in the values.yaml file and replace it with a configuration similar to the following:\ncustomRules: custom-rules.yaml: |- - rule: Example rule desc: ... ... - rule: Example rule 2 ... more-custom-rules.yaml: |- - rule: ... ... That will instruct Helm to create as many rules files as you define here accessible inside the Falco Pods, under the directory /etc/falco/rules.d.\nFinally, remember that keeping any previous ruleset and extending it, although sometimes recommended, is not enforced. It's acceptable to create a new ruleset by reorganizing the upstream rules, reordering and rewriting them, mixing in custom rules, splitting them into different sets and files, etc. Default Falco rules should be considered more of a guidance than a requirement to adopt.\nTo learn more about tweaking the Falco configuration to install new rules, see the documentation about default and local rules.\nRules Structure Rules in Falco are defined using YAML syntax. Each rule is represented as an object in a YAML list, denoted by using a hyphen (-) before the first key in the rule. When creating a new rule, several essential keys should be included:\n- rule: desc: condition: output: priority: tags: The rule key will indicate this is a rule to consider when processing the full set of rules. Without this key, Falco will ignore that entry. It has to be unique to create a new rule. Otherwise, it will overwrite any previously defined rule with the same value.\nThe desc key provides a detailed description of the rule's purpose, behavior, or the events it aims to detect. It helps with understanding the rule's intent and assists in documentation. Missing this key in the rule will make Falco show the error message:\nLOAD_ERR_YAML_VALIDATE (Error validating internal structure of YAML file): Item has no mapping for key \u0026#39;desc\u0026#39; The priority key represents the severity of the alert triggered by Falco and corresponds with the well-known Syslog severities: emergency, alert, critical, error, warning, notice, informational, and debug. Missing this key in the rule will make Falco show the error message:\nLOAD_ERR_YAML_VALIDATE (Error validating internal structure of YAML file): Item has no mapping for key \u0026#39;priority\u0026#39; The condition key defines the conditions that must be satisfied for the rule to trigger an alert. It consists of one or more expressions or statements that evaluate to true when the desired event occurs. Missing this key in the rule will make Falco show the error message:\nLOAD_ERR_YAML_VALIDATE (Error validating internal structure of YAML file): Item has no mapping for key \u0026#39;condition\u0026#39; The output key determines the output format of the alert generated by the rule. It specifies how the alert should be formatted and what information should be included. Missing this key in the rule will make Falco show the error message:\nLOAD_ERR_YAML_VALIDATE (Error validating internal structure of YAML file): Item has no mapping for key \u0026#39;output\u0026#39; The tags key categorizes the ruleset into groups of related rules. Although not mandatory when starting to write a rule, its use is highly recommended at a later stage for management purposes. For further information, refer to the [Tags section of the Style Guide of Falco Rules][/docs/rules/style-guide/#tags)\nRefer to the Advanced Rule Syntax documentation to enhance your Falco rules further. The Style Guide of Falco Rules is also highly recommended to ensure your rules are easier to maintain and share with the community. These resources will provide you with valuable information about additional keys that can be used to augment and customize your Falco rules. Exploring these advanced options will allow you to expand the capabilities and effectiveness of your rules.\nBuilding up the Condition A condition in Falco acts as a checklist of requirements an event must meet to trigger the rule. To comprehend this evaluation process, it is essential to have a grasp of Boolean algebra. Ultimately, the condition will either evaluate to true, triggering the associated alert and bypassing the remaining rules, or evaluate to false, causing the next rule to be evaluated.\nTo achieve the desired effect, it is necessary to consider the Boolean operators: and, or, and not. These operators enable the condition to evaluate one or more situations and produce the desired outcome.\nEach item on the checklist corresponds to a comparison involving the information in the syscall invocation and any relevant metadata that provides additional context. These comparisons employ operators such as =, !=, in, contains, and others. Refer to the section operators in the documentation for a more extensive list of available operators.\nBefore proceeding, it's recommended to refer to the condition syntax documentation, which provides detailed guidance on writing conditions. This resource will offer valuable information to ensure accurate and effective condition creation.\nWhen constructing comparisons within conditions, an extensive set of fields is available for use. To simplify the process, you can consult this list, a handy cheat sheet for writing new rules.\nLeveraging Macros and Lists Additionally, the benefits of using macros and lists when writing rules are worth noting: leveraging these features allows for more straightforward and more concise rule creation while promoting the reuse of conditions that have been thoroughly tested. This approach enhances maintainability and efficiency in rule development.\nObserve the following rule that detects when a bash shell is spawned inside a container:\n- rule: Example Rule condition: container.id != host and proc.name = bash and evt.type = execve and proc.pname exists and not proc.pname in (bash, docker) could be rewritten as:\n- rule: Example Rule condition: container and proc.name = bash and spawned_process and proc.pname exists and not proc.pname in (bash, docker) where container and spawned_process are macros already included in the default falco ruleset.\nWe can even go one step beyond adding a list of our own:\n- list: allowed_binaries items: [bash, docker] Allowing us to rewrite the rule as:\n- rule: Example Rule condition: container and proc.name = bash and spawned_process and proc.pname exists and not proc.pname in allowed_binaries Evaluation Priorities When using the boolean operator or, it is crucial to include evaluation priorities by utilizing parentheses ( and ). These parentheses can be nested, and it is recommended to incorporate them within macros as they become part of larger conditions. Neglecting to use parentheses appropriately may lead to unexpected results that differ from the intended outcome.\nConsider the following example to demonstrate the appropriate use of parentheses for setting evaluation priorities. Please note that the rule is quite extensive, indicated by the \u0026gt; symbol in YAML syntax, which signifies that it spans across multiple lines:\n- rule: Example Rule desc: An illustrative rule demonstrating evaluation priority with parentheses condition: \u0026gt; (syscall.type = execve and proc.name = \u0026#34;/bin/bash\u0026#34;) or (syscall.type = open and (fd.name contains \u0026#34;/etc/passwd\u0026#34; or fd.name contains \u0026#34;/etc/shadow\u0026#34;)) output: Log the relevant event. priority: debug In this example, the condition is structured to prioritize specific evaluations through the use of parentheses. It ensures that the rule triggers an alert when either the execve syscall type is matched and the process name is /bin/bash, or when the open syscall type is matched and the file descriptor name contains either /etc/passwd or /etc/shadow.\nThe proper placement of parentheses allows for accurate evaluation and ensures that the rule behaves as intended.\nFalse Positives and Negatives As previously explained, the condition key includes all the necessary checks an event must satisfy to trigger a specific rule. If there are too few checks in the condition, the rule might become too general and trigger frequently, potentially resulting in many false positives. These broad conditions can be useful for initial testing to ensure the rule is being reached and triggered. If the rule is never triggered, it suggests that a previous rule may be capturing the event before it reaches the intended rule.\nAn example of a rule that is too general is provided below:\n- rule: Too General Rule desc: An example of a rule that is an overly broad condition: \u0026gt; proc.name != \u0026#34;systemd\u0026#34; and evt.type = execve output: Log the relevant event. priority: debug Another example would be a rule designed to monitor all activity generated by a specific process, like:\n- rule: Monitor only a process named malicious desc: Another example of an overly broad rule condition: proc.name = malicious output: The process %proc.name has used the syscall %evt.type priority: debug While these examples are useful for initial testing and gathering samples from certain commands, it's important to note that they are too general to yield reliable alerts. Instead, these broad examples are more likely to generate many false positives.\nOn the contrary, if a condition becomes overly specific or contradictory, it may fail to trigger when necessary, resulting in what is known as false negatives. To illustrate this point, consider the following example:\n- rule: Example of a too-specific rule ... condition: evt.type = execve and proc.name = malicious and proc.pid = 1 output: The process %proc.name has used the syscall %evt.type The previous rule would seldom trigger because it relies on a specific PID (Process ID) for the process, which may only occur if executed within a container. While this example represents an extreme case, it highlights the consequences of being excessively specific when defining a condition. It emphasizes that overly specific conditions can lead to infrequent triggering or potentially not triggering in real-world scenarios.\nTuning a Rule by adding Exceptions to it Adding exceptions to an existing Falco rule is a useful approach when you want to exclude specific scenarios from triggering that rule. Instead of using the and not operators in the condition, which can make the condition more complex and harder to understand, Falco provides a recommended method for handling exceptions.\nTo add exceptions to a rule, you can utilize the exceptions key within the rule definition. Specifying one or more conditions under the exceptions key allows you to define scenarios where the rule should not be triggered, even if the main condition is satisfied. This approach enhances the readability and maintainability of the rule by explicitly stating the exceptions separately.\nConsidering the following simplified rule:\n- rule: Launch Privileged Container desc: Detect the start of a privileged container. condition: \u0026gt; container_started and container and container.privileged=true output: Privileged container One way of adding exceptions would be using the and not combination explained above:\n- list: trusted_images items: [docker.io/user/image1, quay.io/user/image2] rule: Launch Privileged Container desc: Detect the start of a privileged container. Exceptions are made for known trusted images. condition: \u0026gt; container_started and container and container.privileged=true and not ( container.image.repository in (trusted_images) or container.image.repository startswith registry.local/ ) output: Privileged container priority: debug The same example using the exceptions key:\n- rule: Launch Privileged Container desc: Detect the start of a privileged container. condition: \u0026gt; container_started and container and container.privileged=true output: Privileged container priority: debug exceptions: - name: trusted_images fields: [container.image.repository] comps: [in] values: - [(trusted_images)] - name: local_images fields: [container.image.repository] comps: [startswith] values: - [registry.local/] While this may seem exaggerated for the provided exceptions, it highlights the true strength of the exceptions key when dealing with a larger number of variables. To demonstrate this, let's explore another example:\n- rule: Launch Privileged Container desc: Detect the start of a privileged container. Exceptions are made for known trusted images. condition: \u0026gt; container_started and container and container.privileged=true and not ((container.image.repository = registry.local/user/java-app and proc.name = /usr/bin/java ) or (container.image.repository = docker.io/user/httpd and proc.name = /usr/bin/httpd ) or (container.image.repository = quay.io/user/mysql and proc.name = /usr/bin/mysqld )) output: Privileged container priority: debug Using the exceptions key it would now look like:\n- rule: Launch Privileged Container desc: Detect the start of a privileged container. condition: \u0026gt; container_started and container and container.privileged=true output: Privileged container priority: debug exceptions: - name: trusted_images fields: [container.image.repository, proc.name] comps: [=,=] values: - [ registry.local/user/java-app, /usr/bin/java ] - [ docker.io/user/httpd, /usr/bin/httpd ] - [ quay.io/user/mysql, /usr/bin/mysqld ] In the last rule provided, you can observe the inclusion of three exceptions, each containing two conditions. When the rules parser processes these conditions, it expands them into a format the rules engine can comprehend and utilize for evaluation. The values of the comps key may differ depending on the complexity of our conditions, and in some cases, multiple exception groups might be required to accommodate the rule's requirements.\nAlthough this example remains relatively straightforward, it effectively demonstrates the capability and versatility of the exceptions key in handling various conditions and exceptions. This feature empowers you to create more sophisticated and specific rules while maintaining clarity and simplicity in the rule definition.\nSelecting the System Call to monitor The kernel provides many system calls that enable processes and libraries to interact with various system resources. These system calls cover a wide range of tasks, from starting new processes to opening files or network sockets, allowing us to gain insights into the actions attempted by processes.\nTo illustrate this, let's consider a fictional example. When given appropriate permissions, the following code can elevate privileges for a user executing it.\n#define _GNU_SOURCE #include \u0026lt;unistd.h\u0026gt; #include \u0026lt;stdlib.h\u0026gt; #include \u0026lt;sys/wait.h\u0026gt; int main(int argc, char* argv[]) { setresuid(0, 0, 0); int pid = fork();\nif (pid == 0) { system(\u0026amp;#34;/bin/bash\u0026amp;#34;); } else { wait(\u0026amp;amp;pid); } return 0; } To compile it, use your favorite Linux C compiler and set the SUID bit on the binary. We are doing a static compilation here to simplify our example here.\n# cc -static -o /tmp/malicious malicious.c # chmod u+s /tmp/malicious # ls -l /tmp/malicious -rwsr-xr-x 1 root root 16888 Jan 11:30 /tmp/malicious Executed as a regular user, it should grant them a root shell:\n$ /tmp/malicious # To observe what this program does once executed, we'll use strace:\n$ strace /tmp/malicious execve(\u0026#34;/tmp/malicious\u0026#34;, [\u0026#34;/tmp/malicious\u0026#34;], 0x7ffeaaf27690 /* 24 vars */) = 0 access(\u0026#34;/etc/suid-debug\u0026#34;, F_OK) = -1 ENOENT (No such file or directory) arch_prctl(0x3001 /* ARCH_??? */, 0x7ffd8b18f0c0) = -1 EINVAL (Invalid argument) brk(NULL) = 0x1f09000 brk(0x1f0a1c0) = 0x1f0a1c0 arch_prctl(ARCH_SET_FS, 0x1f09880) = 0 uname({sysname=\u0026#34;Linux\u0026#34;, nodename=\u0026#34;vagrant\u0026#34;, ...}) = 0 readlink(\u0026#34;/proc/self/exe\u0026#34;, \u0026#34;/tmp/malicious\u0026#34;, 4096) = 14 brk(0x1f2b1c0) = 0x1f2b1c0 brk(0x1f2c000) = 0x1f2c000 mprotect(0x4bf000, 12288, PROT_READ) = 0 fcntl(0, F_GETFD) = 0 fcntl(1, F_GETFD) = 0 fcntl(2, F_GETFD) = 0 setresuid(0, 0, 0) = -1 EPERM (Operation not permitted) clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x1f09b50) = 18104 wait4(-1, Pay attention to the Operation not permitted message when trying to run the command:\nsetresuid(0, 0, 0) = -1 EPERM (Operation not permitted) The reason is that the command strace doesn't have enough permissions to let /tmp/malicious escalate privileges. But that doesn't mean we can't use that information to detect when a program tries it.\nLet's now build a rule to detect that behavior.\n- rule: Detect privilege escalation in /tmp desc: Detect privilege escalationof binaries executed in /tmp condition: \u0026gt; evt.type = setresuid and proc.exepath startswith /tmp/ output: \u0026#34;The binary %proc.name has tried to escalate privileges: %evt.args\u0026#34; priority: debug When we execute our binary once more, the triggered rule should produce an output similar to the following:\nDebug The binary malicious has tried to escalate privileges: ruid=0(root) euid=0(root) suid=0(root) This rule may appear overly simplistic, potentially leading to numerous false positives or negatives. However, it illustrates how gaining a comprehensive understanding of binaries, their behaviors, and the associated threats can significantly improve the quality of our rule writing. By delving deeper into these aspects, we can craft more effective and accurate rules to enhance the detection capabilities of Falco.\n","summary":"","tags":null,"title":"Custom Ruleset","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/custom-ruleset/"},{"category":"docs","content":"Here are some examples of the types of behavior falco can detect.\nFor a more comprehensive set of examples, see the full rules file at falco_rules.yaml.\nA shell is run in a container \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;container\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: container.id != host - macro: spawned_process condition: (evt.type in (execve, execveat)) - rule: run_shell_in_container desc: a shell was spawned by a non-shell program in a container. Container entrypoints are excluded. condition: container and proc.name = bash and spawned_process and proc.pname exists and not proc.pname in (bash, docker) output: \u0026quot;Shell spawned in a container other than entrypoint | user=%user.name container_id=%container.id container_name=%container.name shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline\u0026quot; priority: WARNING Unexpected outbound Elasticsearch connection \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;outbound\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: syscall.type=connect and (fd.typechar=4 or fd.typechar=6) - macro: elasticsearch_cluster_port condition: fd.sport=9300 - rule: elasticsearch_unexpected_network_outbound desc: outbound network traffic from elasticsearch on a port other than the standard ports condition: user.name = elasticsearch and outbound and not elasticsearch_cluster_port output: \u0026quot;Outbound network traffic from Elasticsearch on unexpected port | connection=%fd.name\u0026quot; priority: WARNING Write to directory holding system binaries \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;open_write\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: \u0026gt; (evt.type=open or evt.type=openat) and fd.typechar='f' and (evt.arg.flags contains O_WRONLY or evt.arg.flags contains O_RDWR or evt.arg.flags contains O_CREAT or evt.arg.flags contains O_TRUNC) - macro: package_mgmt_binaries condition: proc.name in (dpkg, dpkg-preconfigu, rpm, rpmkey, yum) - macro: bin_dir condition: fd.directory in (/bin, /sbin, /usr/bin, /usr/sbin) - rule: write_binary_dir desc: an attempt to write to any file below a set of binary directories condition: open_write and not package_mgmt_binaries and bin_dir output: \u0026quot;File below a known binary directory opened for writing | user=%user.name command=%proc.cmdline file=%fd.name\u0026quot; priority: WARNING Non-authorized container namespace change \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;rule\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;change_thread_namespace\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; desc: an attempt to change a program/thread\u0026amp;#39;s namespace (commonly done as a part of creating a container) by calling setns. condition: syscall.type = setns and not proc.name in (docker, sysdig, dragent) output: \u0026quot;Namespace change (setns) by unexpected program | user=%user.name command=%proc.cmdline container=%container.id\u0026quot; priority: WARNING Non-device files written in /dev (some rootkits do this) \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;rule\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;create_files_below_dev\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; desc: creating any files below /dev other than known programs that manage devices. Some rootkits hide files in /dev. condition: (evt.type = creat or evt.arg.flags contains O_CREAT) and proc.name != blkid and fd.directory = /dev and fd.name != /dev/null output: \u0026quot;File created below /dev by untrusted program | user=%user.name command=%proc.cmdline file=%fd.name\u0026quot; priority: WARNING Process other than skype/webex tries to access camera \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;rule\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;access_camera\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; desc: a process other than skype/webex tries to access the camera condition: evt.type = open and fd.name = /dev/video0 and not proc.name in (skype, webex) output: Unexpected process opening camera video device | command=%proc.cmdline priority: WARNING ","summary":"","tags":null,"title":"Rules Examples","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/rules/examples/"},{"category":"docs","content":" The gRPC Output as well as the embedded gRPC server have been deprecated in Falco 0.43.0 and will be removed in a future release. Until removal and since Falco 0.43.0, using any of them will result in a warning informing the user about the deprecation. Users are encouraged to leverage another output and/or Falcosidekick, as the usage will result in an error after the removal.\n// SPDX-License-Identifier: Apache-2.0 /* Copyright (C) 2023 The Falco Authors. Licensed under the Apache License, Version 2.0 (the \u0026#34;License\u0026#34;); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an \u0026#34;AS IS\u0026#34; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ syntax = \u0026#34;proto3\u0026#34;; import \u0026#34;google/protobuf/timestamp.proto\u0026#34;; import \u0026#34;schema.proto\u0026#34;; package falco.outputs; option go_package = \u0026#34;github.com/falcosecurity/client-go/pkg/api/outputs\u0026#34;; // This service defines the RPC methods // to `request` a stream of output `response`s. service service { // Subscribe to a stream of Falco outputs by sending a stream of requests. rpc sub(stream request) returns (stream response); // Get all the Falco outputs present in the system up to this call. rpc get(request) returns (stream response); } // The `request` message is the logical representation of the request model. // It is the input of the `output.service` service. message request { // TODO(leodido,fntlnz): tags not supported yet, keeping it for reference. // repeated string tags = 1; } // The `response` message is the representation of the output model. // It contains all the elements that Falco emits in an output along with the // definitions for priorities and source. message response { google.protobuf.Timestamp time = 1; falco.schema.priority priority = 2; falco.schema.source source_deprecated = 3 [deprecated=true]; string rule = 4; string output = 5; map\u0026lt;string, string\u0026gt; output_fields = 6; string hostname = 7; repeated string tags = 8; string source = 9; }","summary":"","tags":null,"title":"Outputs","url":"https://v0-43--falcosecurity.netlify.app/docs/developer-guide/grpc/outputs/"},{"category":"docs","content":"Disable Default Rules Even though Falco provides a quite powerful default ruleset, you sometimes need to disable some of these default rules since they do not work properly in your environment. Luckily Falco offers you multiple possibilities to do so.\nVia Falco Configuration or Parameters Since Falco 0.38.0, you can control which rules are loaded by adding relevant entries to the rules section of the falco.yaml configuration file or by passing appropriate command line parameters. In the rules section you can add any number of enable or disable entries:\n- enable: rule: \u0026lt;wildcard pattern\u0026gt; - disable: rule: \u0026lt;wildcard pattern\u0026gt; - enable: tag: \u0026lt;tag\u0026gt; - disable: tag: \u0026lt;tag\u0026gt; All the entries are treated as commands and evaluated in order, thus controlling the enabled status of the loaded rules. For instance, in order to only enable the rules called Netcat Remote Code Execution in Container and Delete or rename shell history you can supply the following configuration:\nrules: - disable: rule: \u0026#34;*\u0026#34; - enable: rule: Netcat Remote Code Execution in Container - enable: rule: Delete or rename shell history The above instructs Falco to first disable all rules (regardless of their enabled status in the files or any override), then enable the Netcat rule and finally enable the deletion rule.\nAlternatively, this configuration can be supplied on the Falco command line by using the -o option.\nfalco -o \u0026#34;rules[].enable.tag=network\u0026#34; -o \u0026#34;rules[].enable.rule=Directory traversal monitored file\u0026#34; -o \u0026#34;rules[].enable.rule=k8s_*\u0026#34; -o \u0026#34;rules[].disable.rule=k8s_noisy_rule\u0026#34; In the above example, all the rules tagged network are enabled, the Directory traversal monitored file will also be enabled alongside any rule matching the pattern k8s_*, and then the rule k8s_noisy_rule will be disabled; all of this happens regardless of any enabled status specified in the rules files. If both yaml configuration and -o options are specified, the CLI options are applied last.\nThese parameters can also be specified as Helm chart value (extraArgs) if you are deploying Falco via the official Helm chart.\nVia existing Macros Most of the default rules offer some kind of user_* macros which are already part of the rule conditions. These user_* macros are usually set to (never_true) or (always_true) which basically enables or disables the regarding rule. Now if you want to disable a default rule (e.g. Read sensitive file trusted after startup), you just have to override the rule's user_* macro (user_known_read_sensitive_files_activities in this case) inside your custom Falco configuration.\nExample for your custom Falco configuration (note the (always_true) condition):\n- macro: user_known_read_sensitive_files_activities condition: (always_true) Please note again that the order of the specified configuration file matters! The last defined macro with the same name wins.\nVia Custom Rule Definition The enabled attribute used as an override is deprecated and it will be removed in Falco 1.0.0. Use the override.enabled attribute instead. Please note that the enabled key is only deprecated when used as an override! So a rule like this is perfectly legit:\n- rule: legit_rule desc: legit rule description condition: evt.type=open output: user=%user.name command=%proc.cmdline file=%fd.name priority: INFO enabled: false Last but not the least, you can just disable a rule that is enabled by default using the enabled: false rule property. This is especially useful for rules which do not provide a user_* macro in the default condition.\nEnsure that the custom configuration file loads after the default configuration file. You can configure the right order using multiple -r parameters or directly inside the falco configuration file falco.yaml through rules_files. If you are using the official Helm chart, then configure the order with the falco.rules_files value.\nFor example to disable the User mgmt binaries default rule in /etc/falco/falco_rules.yaml define a custom rule in /etc/falco/rules.d/custom-rules.yaml:\n- rule: User mgmt binaries enabled: false At the same time, disabled rules can be re-enabled by using the enabled: true rule property. For instance, the Change thread namespace rule in /etc/falco/falco_rules.yaml that is disabled by default, can be manually enabled with:\n- rule: Change thread namespace enabled: true Rule Tags As of 0.6.0, rules have an optional set of tags that are used to categorize the ruleset into groups of related rules. Here's an example:\n- rule: File Open by Privileged Container desc: Any open by a privileged container. Exceptions are made for known trusted images. condition: (open_read or open_write) and container and container.privileged=true and not trusted_containers output: File opened for read/write by privileged container | user=%user.name command=%proc.cmdline file=%fd.name priority: WARNING tags: [container, cis] In this case, the rule \u0026quot;File Open by Privileged Container\u0026quot; has been given the tags \u0026quot;container\u0026quot; and \u0026quot;cis\u0026quot;. If the tags key is not present for a given rule or the list is empty, a rule has no tags.\nHere's how you can use tags:\nYou can use the -T \u0026lt;tag\u0026gt; argument to disable rules having a given tag. -T can be specified multiple times. For example, to skip all rules with the \u0026quot;filesystem\u0026quot; and \u0026quot;cis\u0026quot; tags you would run falco with falco -T filesystem -T cis .... -T can not be specified with -t. You can use the -t \u0026lt;tag\u0026gt; argument to only run those rules having a given tag. -t can be specified multiple times. For example, to only run those rules with the \u0026quot;filesystem\u0026quot; and \u0026quot;cis\u0026quot; tags, you would run falco with falco -t filesystem -t cis .... -t can not be specified with -T or -D \u0026lt;pattern\u0026gt; (disable rules by rule name regex). Tags for Current Falco Ruleset We've also gone through the default ruleset and tagged all the rules with an initial set of tags. Here are the tags we've used:\nTag Description filesystem The rule relates to reading/writing files software_mgmt The rule relates to any software/package management tool like rpm, dpkg, etc. process The rule relates to starting a new process or changing the state of a current process database The rule relates to databases host The rule only works outside of containers shell The rule specifically relates to starting shells container The rule only works inside containers cis The rule is related to the CIS Docker benchmark users The rule relates to management of users or changing the identity of a running process network The rule relates to network activity Rules can have multiple tags if they relate to multiple of the above. Every rule in the falco ruleset currently has at least one tag.\nIgnored system calls \u0026lt;p\u0026gt;For performance reasons, some system calls are currently discarded before Falco processes them.\u0026lt;br\u0026gt; You can see the complete list by running falco with -i.\nIf you'd like to run Falco against all events, including system calls in the above list,\nyou can run Falco with the -A flag.\nFor more information, see supported events.\n","summary":"","tags":null,"title":"Controlling Rules","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/controlling-rules/"},{"category":"docs","content":"Introduction Almost all Falco Rules have cases where the behavior detected by the rule should be allowed. For example, the rule Write below binary dir has exceptions for specific programs that are known to write below these directories as a part of software installation/management:\n- rule: Write below binary dir desc: an attempt to write to any file below a set of binary directories condition: \u0026gt; open_write and bin_dir and not package_mgmt_procs and not exe_running_docker_save and not python_running_get_pip and not python_running_ms_oms and not user_known_write_below_binary_dir_activities ... Previously, these exceptions were expressed as concatenations to the original rule's condition. For example, looking at the macro package_mgmt_procs:\n- macro: package_mgmt_procs condition: proc.name in (package_mgmt_binaries) The result is appending and not proc.name in (package_mgmt_binaries) to the condition of the rule.\nA more extreme case of this is the write_below_etc macro used by Write below etc rule. It had tens of exceptions:\n... and not sed_temporary_file and not exe_running_docker_save and not ansible_running_python and not python_running_denyhosts and not fluentd_writing_conf_files and not user_known_write_etc_conditions and not run_by_centrify and not run_by_adclient and not qualys_writing_conf_files and not git_writing_nssdb ... The exceptions all generally follow the same structure: naming a program and a directory prefix below /etc where that program is allowed to write files.\nRule Exceptions Starting in 0.28.0, Falco supports an optional exceptions property to rules. The exceptions key is a list of identifier plus list of tuples of filtercheck fields. Here's an example:\n- rule: Write below binary dir desc: an attempt to write to any file below a set of binary directories condition: \u0026gt; open_write and bin_dir and not package_mgmt_procs and not exe_running_docker_save and not python_running_get_pip and not python_running_ms_oms and not user_known_write_below_binary_dir_activities exceptions: - name: proc_writer fields: [proc.name, fd.directory] comps: [=, =] values: - [my-custom-yum, /usr/bin] - [my-custom-apt, /usr/local/bin] - name: cmdline_writer fields: [proc.cmdline, fd.directory] comps: [startswith, =] - name: container_writer fields: [container.image.repository, fd.directory] - name: proc_filenames fields: [proc.name, fd.name] comps: [=, in] values: - [my-custom-dpkg, [/usr/bin, /bin]] - name: filenames fields: fd.filename comps: in This rule defines four kinds of exceptions:\nproc_writer: uses a combination of proc.name and fd.directory cmdline_writer: uses a combination of proc.cmeline and fd.directory container_writer: uses a combination of container.image.repository and fd.directory proc_filenames: uses a combination of process and list of filenames. filenames: uses a list of filenames The specific strings proc_writer/container_writer/proc_filenames/filenames are arbitrary strings and don't have a special meaning to the rules file parser. They're only used to provide a handy name, and to potentially link together values in a later rule override (more on that below).\nNotice that exceptions are defined as a part of the rule. This is important because the author of the rule defines what construes a valid exception to the rule. In this case, an exception can consist of a process and file directory (actor and target), but not a process name only (too broad).\nThe fields property contains one or more fields that will extract a value from the events. The comps property contains comparison operators that align 1-1 with the items in the fields property. The values property contains tuples of values. Each item in the tuple should align 1-1 with the corresponding field and comparison operator. Together, each tuple of values is combined with the fields/comps to modify the condition to add an exclusion to the rule's condition.\nFor example, for the exception proc_writer above, the fields/comps/values are the equivalent of adding the following to the rule's condition:\n... and not ((proc.name=my-custom-yum and fd.directory=/usr/bin) or (proc.name=my-custom-apt and fd.directory=/usr/local/bin)) Note that when a comparison operator is in, the corresponding values tuple item should be a list. proc_filenames above uses that syntax, and is the equivalent of:\n... and not (proc.name=my-custom-dpkg and fd.name in (/usr/bin, /bin)) Exception Syntax Shortcuts In general, the value for an exceptions fields property should always be a list of fields. The comps property must be an equal-length list of comparison operators, and the values property must be a list of tuples, where each tuple has the same length as the fields/comps lists.\nHowever, there are a few shortcuts that can be used when defining an exception:\nValues are Optional A rule may define fields and comps, but not define values. This allows a later rule override to add values to an exception (more on that below). The exception cmdline_writer above has this format:\n- name: cmdline_writer fields: [proc.cmdline, fd.directory] comps: [startswith, =] Fields/Comps Can Be a Single Value, Not a List An alternative way to define an exception is to have fields containing a single field and comps containing a single comparison operator (which must be one of in, pmatch, intersects). In this format, values is a list of values rather than list of tuples. The exception filenames above has this format:\n- name: filenames fields: fd.filename comps: in In this case, the exception is the equivalent of:\n... and not (fd.filename in (...)) Comps is Optional If comps is not provided, a default value is filled in. When fields is a list, comps will be set to an equal-length list of = operators. The exception container_writer above has that format, and is equivalent to:\n- name: container_writer fields: [container.image.repository, fd.directory] comps: [=, =] When fields is a single field, comps is set to a single in operator.\nAppending Exception Values Exception values will most commonly be defined in rules overrides. Here's an example:\n- list: apt_files items: [/bin/ls, /bin/rm] - rule: Write below binary dir exceptions: - name: proc_writer values: - [apk, /usr/lib/alpine] - [npm, /usr/node/bin] - name: container_writer values: - [docker.io/alpine, /usr/libexec/alpine] - name: proc_filenames values: - [apt, [apt_files]] - [rpm, [/bin/cp, /bin/pwd]] - name: filenames values: [python, go] override: exceptions: append In this case, the values are appended to any values for the base rule, and then the fields/comps/values are added to the rule's condition.\nPutting it all together, the effective rule condition for this rule is:\n... and not ((proc.name=my-custom-yum and fd.directory=/usr/bin) or # proc_writer (proc.name=my-custom-apt and fd.directory=/usr/local/bin) or (proc.name=apk and fd.directory=/usr/lib/alpine) or (proc.name=npm and fd.directory=/usr/node/bin) or (container.image.repository=docker.io/alpine and fd.name=/usr/libexec/alpine) or # container_writer (proc.name=apt and fd.name in (apt_files)) or # proc_filenames (proc.name=rpm and fd.name in (/bin/cp, /bin/pwd)) or (fd.filename in (python, go)) # filenames Replacing Exception Values It's possible to replace the entire list(s) of values tuples for specific exception(s) by following the rules overriding syntax and specifying exceptions: replace. Here's an example:\n- list: apt_files items: [/bin/ls, /bin/rm] - rule: Write below binary dir exceptions: - name: proc_writer values: - [apk, /usr/lib/alpine] - [npm, /usr/node/bin] - name: container_writer values: - [docker.io/alpine, /usr/libexec/alpine] - name: proc_filenames values: - [apt, [apt_files]] - [rpm, [/bin/cp, /bin/pwd]] - name: filenames values: [python, go] override: exceptions: replace Here, the values lists for the proc_writer, container_writer, proc_filenames and filenames exceptions will be replaced (or initialized) with the corresponding values lists, Putting it all together, the effective rule condition for this rule will be:\n... and not ((proc.name=apk and fd.directory=/usr/lib/alpine) or # proc_writer (proc.name=npm and fd.directory=/usr/node/bin) or (container.image.repository=docker.io/alpine and fd.name=/usr/libexec/alpine) or # container_writer (proc.name=apt and fd.name in (apt_files)) or # proc_filenames (proc.name=rpm and fd.name in (/bin/cp, /bin/pwd)) or (fd.filename in (python, go)) # filenames Guidelines For Adding Exceptions To Rules The default rules files have been revamped to use exceptions whenever possible, and are a good reference for best practices when defining exceptions for rules. Here are some other guidelines to follow:\nBe Specific When defining an exception, try to think about the actor, action, and target, and whenever possible use all three items for an exception. For example, instead of simply using proc.name or container.image.repository for a file-based exception, also include the file being acted on via fd.name, fd.directory, etc. Similarly, if a rule is container-specific, don't only include the image container.image.repository, also include the process name proc.name.\nUse Set Operators If an exception involves a set of process names, file paths, etc., combine the process names into a list and use the in/pmatch operator to handle the values in a single exception. Here's an example:\n- name: proc_file fields: [proc.name, fd.name] comps: [in, in] values: - [[qualys-cloud-ag], [/etc/qualys/cloud-agent/qagent-log.conf]] - [[update-haproxy-,haproxy_reload.], [/etc/openvpn/client.map]] - [[start-fluentd], [/etc/fluent/fluent.conf, /etc/td-agent/td-agent.conf]] This exception matches process name and path, but allows for multiple process names writing to any of a set of files.\nMore Information The original proposal describes the benefits of exceptions in more detail.\n","summary":"","tags":null,"title":"Rule Exceptions","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/exceptions/"},{"category":"docs","content":"If you'd like to check if Falco is working properly, we have the event-generator tool that can perform an activity for both our syscalls and k8s audit related rules.\nThe tool provides a command to run either some or all sample events.\nevent-generator run [regexp] Without arguments it runs all actions, otherwise only those actions matching the given regular expression.\nThe full command line documentation is here.\nDownloads Artifacts Version binaries download link container images docker pull falcosecurity/event-generator:latest Sample events WARNING\nSince some commands might alter your system, we strongly recommend that you run the program within a container (see below).\nFor example, some actions modify files and directories below /bin, /etc, /dev, etc.\nSystem Call Activity The syscall collection performs a variety of suspect actions that are detected by the default Falco ruleset.\ndocker run -it --rm falcosecurity/event-generator run syscall --loop The above command loops forever, incessantly generating a sample event each second.\nKubernetes Auditing Activity The k8saudit collection generates activity that matches the k8s audit event ruleset.\nevent-generator run k8saudit --loop The above command loops forever, creating resources in the current namespace and deleting them after each iteration. Use the --namespace option to choose a different namespace.\nRunning the Event Generator in K8s We've also provided a helm chart that make it easy to run the event generator in K8s Clusters.\nFirst thing, we need to add the falcosecurity charts repository:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update Once you have the helm repo configured, you can run the following to create the necessary objects in the event-generator namespace and then generate events continuously:\nhelm install event-generator falcosecurity/event-generator \\ --namespace event-generator \\ --create-namespace \\ --set config.loop=false \\ --set config.actions=\u0026#34;\u0026#34; The above command applies to the event-generator namespace. Use the --namespace option to deploy in a different namespace. Events will be generated in the same namespace.\nYou can also find more examples in the event-generator and charts repositories.\n","summary":"","tags":null,"title":"Generating sample events","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/event-sources/kernel/sample-events/"},{"category":"docs","content":"Here are the fields supported by Falco. These fields can be used in the condition key of a Falco rule and well as the output key. Any fields included in the output key of a rule will also be included in the alert's output_fields object when json_output is set to true.\nYou can also see this set of fields via falco --list=\u0026lt;source\u0026gt;, with \u0026lt;source\u0026gt; being one of the Falco event sources.\nSystem Calls (source syscall) syscall event source fields are provided by the Falco Drivers. See the supported events documentation to learn about all the available event types. The field evt.arg, evt.args and evt.rawarg is used to access arguments for each event. For example, in order to access the target arg of a symlinkat exit event you can use evt.arg.target.\n# System Kernel Fields $ falco --list=syscall \u0026lt;h3 id=\u0026quot;field-class-evt\u0026quot;\u0026gt;Field Class: evt\u0026lt;/h3\u0026gt; These fields can be used for all event types\nName Type Description evt.num UINT64 event number. evt.time CHARBUF event timestamp as a time string that includes the nanosecond part. evt.time.s CHARBUF event timestamp as a time string with no nanoseconds. evt.time.iso8601 CHARBUF event timestamp in ISO 8601 format, including nanoseconds and time zone offset (in UTC). evt.datetime CHARBUF event timestamp as a time string that includes the date. evt.datetime.s CHARBUF event timestamp as a datetime string with no nanoseconds. evt.rawtime ABSTIME absolute event timestamp, i.e. nanoseconds from epoch. evt.rawtime.s ABSTIME integer part of the event timestamp (e.g. seconds since epoch). evt.rawtime.ns ABSTIME fractional part of the absolute event timestamp. evt.reltime RELTIME number of nanoseconds from the beginning of the capture. evt.reltime.s RELTIME number of seconds from the beginning of the capture. evt.reltime.ns RELTIME fractional part (in ns) of the time from the beginning of the capture. evt.pluginname CHARBUF if the event comes from a plugin-defined event source, the name of the plugin that generated it. The plugin must be currently loaded. evt.plugininfo CHARBUF if the event comes from a plugin-defined event source, a summary of the event as formatted by the plugin. The plugin must be currently loaded. evt.source CHARBUF the name of the source that produced the event. evt.is_async BOOL 'true' for asynchronous events, 'false' otherwise. evt.asynctype CHARBUF If the event is asynchronous, the type of the event (e.g. 'container'). evt.hostname CHARBUF The hostname of the underlying host can be customized by setting an environment variable (e.g. FALCO_HOSTNAME for the Falco agent). This is valuable in Kubernetes setups, where the hostname can match the pod name particularly in DaemonSet deployments. To achieve this, assign Kubernetes' spec.nodeName to the environment variable. Notably, spec.nodeName generally includes the cluster name. Field Class: evt (for system calls) Event fields applicable to syscall events. Note that for most events you can access the individual arguments/parameters of each syscall via evt.arg, e.g. evt.arg.filename.\nName Type Description evt.deltatime RELTIME delta between this event and the previous event, in nanoseconds. evt.deltatime.s RELTIME integer part of the delta between this event and the previous event. evt.deltatime.ns RELTIME fractional part of the delta between this event and the previous event. evt.type CHARBUF The name of the event (e.g. 'open'). evt.type.is UINT32 allows one to specify an event type, and returns 1 for events that are of that type. For example, evt.type.is.open returns 1 for open events, 0 for any other event. syscall.type CHARBUF For system call events, the name of the system call (e.g. 'open'). Unset for other events (e.g. switch or internal events). Use this field instead of evt.type if you need to make sure that the filtered/printed value is actually a system call. evt.category CHARBUF The event category. Example values are 'file' (for file operations like open and close), 'net' (for network operations like socket and bind), memory (for things like brk or mmap), and so on. evt.cpu INT16 number of the CPU where this event happened. evt.args CHARBUF all the event arguments, aggregated into a single string. evt.arg CHARBUF one of the event arguments specified by name or by number. Some events (e.g. return codes or FDs) will be converted into a text representation when possible. E.g. 'evt.arg.fd' or 'evt.arg[0]'. evt.rawarg DYNAMIC one of the event arguments specified by name. E.g. 'evt.rawarg.fd'. evt.info CHARBUF Currently, this field returns the same value as 'evt.args'. evt.buffer BYTEBUF the binary data buffer for events that have one, like read(), recvfrom(), etc. Use this field in filters with 'contains' to search into I/O data buffers. evt.buflen UINT64 the length of the binary data buffer for events that have one, like read(), recvfrom(), etc. evt.res CHARBUF event return value, as a string. If the event failed, the result is an error code string (e.g. 'ENOENT'), otherwise the result is the string 'SUCCESS'. evt.rawres INT64 event return value, as a number (e.g. -2). Useful for range comparisons. evt.failed BOOL 'true' for events that returned an error status. evt.is_io BOOL 'true' for events that read or write to FDs, like read(), send, recvfrom(), etc. evt.is_io_read BOOL 'true' for events that read from FDs, like read(), recv(), recvfrom(), etc. evt.is_io_write BOOL 'true' for events that write to FDs, like write(), send(), etc. evt.io_dir CHARBUF 'r' for events that read from FDs, like read(); 'w' for events that write to FDs, like write(). evt.is_wait BOOL 'true' for events that make the thread wait, e.g. sleep(), select(), poll(). evt.is_syslog BOOL 'true' for events that are writes to /dev/log. evt.count UINT32 This filter field always returns 1. evt.count.error UINT32 This filter field returns 1 for events that returned with an error. evt.count.error.file UINT32 This filter field returns 1 for events that returned with an error and are related to file I/O. evt.count.error.net UINT32 This filter field returns 1 for events that returned with an error and are related to network I/O. evt.count.error.memory UINT32 This filter field returns 1 for events that returned with an error and are related to memory allocation. evt.count.error.other UINT32 This filter field returns 1 for events that returned with an error and are related to none of the previous categories. evt.count.exit UINT32 This filter field returns 1 for exit events. evt.around UINT64 Accepts the event if it's around the specified time interval. The syntax is evt.around[T]=D, where T is the value returned by %evt.rawtime for the event and D is a delta in milliseconds. For example, evt.around[1404996934793590564]=1000 will return the events with timestamp with one second before the timestamp and one second after it, for a total of two seconds of capture. evt.abspath CHARBUF Absolute path calculated from dirfd and name during syscalls like renameat and symlinkat. Use 'evt.abspath.src' or 'evt.abspath.dst' for syscalls that support multiple paths. evt.is_open_read BOOL 'true' for open/openat/openat2/open_by_handle_at events where the path was opened for reading evt.is_open_write BOOL 'true' for open/openat/openat2/open_by_handle_at events where the path was opened for writing evt.is_open_exec BOOL 'true' for open/openat/openat2/open_by_handle_at or creat events where a file is created with execute permissions evt.is_open_create BOOL 'true' for for open/openat/openat2/open_by_handle_at events where a file is created. Field Class: process Additional information about the process and thread executing the syscall event.\nName Type Description proc.exe CHARBUF The first command-line argument (i.e., argv[0]), typically the executable name or a custom string as specified by the user. It is primarily obtained from syscall arguments, truncated after 4096 bytes, or, as a fallback, by reading /proc/PID/cmdline, in which case it may be truncated after 1024 bytes. This field may differ from the last component of proc.exepath, reflecting how command invocation and execution paths can vary. proc.pexe CHARBUF The proc.exe (first command line argument argv[0]) of the parent process. proc.aexe CHARBUF The proc.exe (first command line argument argv[0]) for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.aexe[1] retrieves the proc.exe of the parent process, proc.aexe[2] retrieves the proc.exe of the grandparent process, and so on. The current process's proc.exe line can be obtained using proc.aexe[0]. When used without any arguments, proc.aexe is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.aexe endswith java to match any process ancestor whose proc.exe ends with the term java. proc.exepath CHARBUF The full executable path of a process, resolving to the canonical path for symlinks. This is primarily obtained from the kernel, or as a fallback, by reading /proc/PID/exe (in the latter case, the path is truncated after 1024 bytes). For eBPF drivers, due to verifier limits, path components may be truncated to 24 for legacy eBPF on kernel \u0026lt;5.2, 48 for legacy eBPF on kernel \u0026gt;=5.2, or 96 for modern eBPF. proc.pexepath CHARBUF The proc.exepath (full executable path) of the parent process. proc.aexepath CHARBUF The proc.exepath (full executable path) for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.aexepath[1] retrieves the proc.exepath of the parent process, proc.aexepath[2] retrieves the proc.exepath of the grandparent process, and so on. The current process's proc.exepath line can be obtained using proc.aexepath[0]. When used without any arguments, proc.aexepath is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.aexepath endswith java to match any process ancestor whose path ends with the term java. proc.name CHARBUF The process name (truncated after 16 characters) generating the event (task-\u0026gt;comm). Truncation is determined by kernel settings and not by Falco. This field is collected from the syscalls args or, as a fallback, extracted from /proc/PID/comm. The name of the process and the name of the executable file on disk (if applicable) can be different if a process is given a custom name which is often the case for example for java applications. proc.pname CHARBUF The proc.name (truncated after 16 characters) of the parent process. proc.aname CHARBUF The proc.name (truncated after 16 characters) for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.aname[1] retrieves the proc.name of the parent process, proc.aname[2] retrieves the proc.name of the grandparent process, and so on. The current process's proc.name line can be obtained using proc.aname[0]. When used without any arguments, proc.aname is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.aname=bash to match any process ancestor whose name is bash. proc.args CHARBUF The arguments passed on the command line when starting the process generating the event excluding argv[0] (truncated after 4096 bytes). This field is collected from the system call arguments, or as a fallback, extracted from /proc/PID/cmdline, can be accessed by specifying proc.args[INDEX], e.g., proc.args[0] or proc.args[1]. The indexing is zero-based, meaning proc.args[0] refers to the first command-line argument passed, rather than argv[0]. proc.aargs CHARBUF The arguments passed on the command line when starting the process generating the event for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.aargs[1] retrieves the arguments passed on the command line of the parent process, proc.aargs[2] retrieves the proc.args of the grandparent process, and so on. The current process's arguments passed on the command line can be obtained using proc.aargs[0]. When used without any arguments, proc.aargs is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.aargs contains base64 to match any process ancestor whose arguments passed on the command line contains the term base64. proc.cmdline CHARBUF The concatenation of proc.name + proc.args (truncated after 4096 bytes) when starting the process generating the event. proc.pcmdline CHARBUF The proc.cmdline (full command line (proc.name + proc.args)) of the parent process. proc.acmdline CHARBUF The full command line (proc.name + proc.args) for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.acmdline[1] retrieves the full command line of the parent process, proc.acmdline[2] retrieves the proc.cmdline of the grandparent process, and so on. The current process's full command line can be obtained using proc.acmdline[0]. When used without any arguments, proc.acmdline is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.acmdline contains base64 to match any process ancestor whose command line contains the term base64. proc.cmdnargs UINT64 The number of command line args (proc.args). proc.cmdlenargs UINT64 The total count of characters / length of the command line args (proc.args) combined excluding whitespaces between args. proc.exeline CHARBUF The full command line, with exe as first argument (proc.exe + proc.args) when starting the process generating the event. proc.env CHARBUF The environment variables of the process generating the event as concatenated string 'ENV_NAME=value ENV_NAME1=value1'. Can also be used to extract the value of a known env variable, e.g. proc.env[ENV_NAME]. proc.aenv CHARBUF [EXPERIMENTAL] This field can be used in three flavors: (1) as a filter checking all parents, e.g. 'proc.aenv contains xyz', which is similar to the familiar 'proc.aname contains xyz' approach, (2) checking the proc.env of a specified level of the parent, e.g. 'proc.aenv[2]', which is similar to the familiar 'proc.aname[2]' approach, or (3) checking the first matched value of a known ENV_NAME in the parent lineage, such as 'proc.aenv[ENV_NAME]' (across a max of 20 ancestor levels). This field may be deprecated or undergo breaking changes in future releases. Please use it with caution. proc.cwd CHARBUF The current working directory of the event. proc.loginshellid INT64 The pid of the oldest shell among the ancestors of the current process, if there is one. This field can be used to separate different user sessions. proc.tty UINT32 The controlling terminal of the process. 0 for processes without a terminal. proc.pid INT64 The id of the process generating the event. proc.ppid INT64 The pid of the parent of the process generating the event. proc.apid INT64 The pid for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.apid[1] retrieves the pid of the parent process, proc.apid[2] retrieves the pid of the grandparent process, and so on. The current process's pid can be obtained using proc.apid[0]. When used without any arguments, proc.apid is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.apid=1337 to match any process ancestor whose pid is equal to 1337. proc.vpid INT64 The id of the process generating the event as seen from its current PID namespace. proc.pvpid INT64 The id of the parent process generating the event as seen from its current PID namespace. proc.sid INT64 The session id of the process generating the event. proc.sname CHARBUF The name of the current process's session leader. This is either the process with pid=proc.sid or the eldest ancestor that has the same sid as the current process. proc.sid.exe CHARBUF The first command line argument argv[0] (usually the executable name or a custom one) of the current process's session leader. This is either the process with pid=proc.sid or the eldest ancestor that has the same sid as the current process. proc.sid.exepath CHARBUF The full executable path of the current process's session leader. This is either the process with pid=proc.sid or the eldest ancestor that has the same sid as the current process. proc.vpgid INT64 The process group id of the process generating the event, as seen from its current PID namespace. proc.vpgid.name CHARBUF The name of the current process's process group leader. This is either the process with proc.vpgid == proc.vpid or the eldest ancestor that has the same vpgid as the current process. The description of proc.is_vpgid_leader offers additional insights. proc.vpgid.exe CHARBUF The first command line argument argv[0] (usually the executable name or a custom one) of the current process's process group leader. This is either the process with proc.vpgid == proc.vpid or the eldest ancestor that has the same vpgid as the current process. The description of proc.is_vpgid_leader offers additional insights. proc.vpgid.exepath CHARBUF The full executable path of the current process's process group leader. This is either the process with proc.vpgid == proc.vpid or the eldest ancestor that has the same vpgid as the current process. The description of proc.is_vpgid_leader offers additional insights. proc.pgid INT64 The process group id of the process generating the event, as seen from host PID namespace. proc.pgid.name CHARBUF The name of the current process's process group leader. This is either the process with proc.pgid == proc.pid or the eldest ancestor that has the same pgid as the current process. The description of proc.is_pgid_leader offers additional insights. proc.pgid.exe CHARBUF The first command line argument argv[0] (usually the executable name or a custom one) of the current process's process group leader. This is either the process with proc.pgid == proc.pid or the eldest ancestor that has the same pgid as the current process. The description of proc.is_pgid_leader offers additional insights. proc.pgid.exepath CHARBUF The full executable path of the current process's process group leader. This is either the process with proc.pgid == proc.pid or the eldest ancestor that has the same pgid as the current process. The description of proc.is_pgid_leader offers additional insights. proc.duration RELTIME Number of nanoseconds since the process started. proc.ppid.duration RELTIME Number of nanoseconds since the parent process started. proc.pid.ts RELTIME Start of process as epoch timestamp in nanoseconds. proc.ppid.ts RELTIME Start of parent process as epoch timestamp in nanoseconds. proc.is_exe_writable BOOL 'true' if this process' executable file is writable by the same user that spawned the process. proc.is_exe_upper_layer BOOL 'true' if this process' executable file is in upper layer in overlayfs. This field value can only be trusted if the underlying kernel version is greater or equal than 3.18.0, since overlayfs was introduced at that time. proc.is_exe_lower_layer BOOL 'true' if this process' executable file is in lower layer in overlayfs. This field value can only be trusted if the underlying kernel version is greater or equal than 3.18.0, since overlayfs was introduced at that time. proc.is_exe_from_memfd BOOL 'true' if the executable file of the current process is an anonymous file created using memfd_create() and is being executed by referencing its file descriptor (fd). This type of file exists only in memory and not on disk. Relevant to detect malicious in-memory code injection. Requires kernel version greater or equal to 3.17.0. proc.is_sid_leader BOOL 'true' if this process is the leader of the process session, proc.sid == proc.vpid. For host processes vpid reflects pid. proc.is_vpgid_leader BOOL 'true' if this process is the leader of the virtual process group, proc.vpgid == proc.vpid. For host processes vpgid and vpid reflect pgid and pid. Can help to distinguish if the process was 'directly' executed for instance in a tty (similar to bash history logging, is_vpgid_leader would be 'true') or executed as descendent process in the same process group which for example is the case when subprocesses are spawned from a script (is_vpgid_leader would be 'false'). proc.is_pgid_leader BOOL 'true' if this process is the leader of the process group, proc.pgid == proc.pid. Can help to distinguish if the process was 'directly' executed for instance in a tty (similar to bash history logging, is_pgid_leader would be 'true') or executed as descendent process in the same process group which for example is the case when subprocesses are spawned from a script (is_pgid_leader would be 'false'). proc.exe_ino INT64 The inode number of the executable file on disk. Can be correlated with fd.ino. proc.exe_ino.ctime ABSTIME Last status change time of executable file (inode-\u0026gt;ctime) as epoch timestamp in nanoseconds. Time is changed by writing or by setting inode information e.g. owner, group, link count, mode etc. proc.exe_ino.mtime ABSTIME Last modification time of executable file (inode-\u0026gt;mtime) as epoch timestamp in nanoseconds. Time is changed by file modifications, e.g. by mknod, truncate, utime, write of more than zero bytes etc. For tracking changes in owner, group, link count or mode, use proc.exe_ino.ctime instead. proc.exe_ino.ctime_duration_proc_start ABSTIME Number of nanoseconds between modifying status of executable image and spawning a new process using the changed executable image. proc.exe_ino.ctime_duration_pidns_start ABSTIME Number of nanoseconds between PID namespace start ts and ctime exe file if PID namespace start predates ctime. proc.pidns_init_start_ts UINT64 Start of PID namespace (container or non container pid namespace) as epoch timestamp in nanoseconds. thread.cap_permitted CHARBUF The permitted capabilities set thread.cap_inheritable CHARBUF The inheritable capabilities set thread.cap_effective CHARBUF The effective capabilities set proc.fdopencount UINT64 Number of open FDs for the process proc.fdlimit INT64 Maximum number of FDs the process can open. proc.fdusage DOUBLE The ratio between open FDs and maximum available FDs for the process. proc.vmsize UINT64 Total virtual memory for the process (as kb). proc.vmrss UINT64 Resident non-swapped memory for the process (as kb). proc.vmswap UINT64 Swapped memory for the process (as kb). thread.pfmajor UINT64 Number of major page faults since thread start. thread.pfminor UINT64 Number of minor page faults since thread start. thread.tid INT64 The id of the thread generating the event. thread.ismain BOOL 'true' if the thread generating the event is the main one in the process. thread.vtid INT64 The id of the thread generating the event as seen from its current PID namespace. thread.exectime RELTIME CPU time spent by the last scheduled thread, in nanoseconds. Exported by switch events only. thread.totexectime RELTIME Total CPU time, in nanoseconds since the beginning of the capture, for the current thread. Exported by switch events only. thread.cgroups CHARBUF All cgroups the thread belongs to, aggregated into a single string. thread.cgroup CHARBUF The cgroup the thread belongs to, for a specific subsystem. e.g. thread.cgroup.cpuacct. proc.nthreads UINT64 The number of alive threads that the process generating the event currently has, including the leader thread. Please note that the leader thread may not be here, in that case 'proc.nthreads' and 'proc.nchilds' are equal proc.nchilds UINT64 The number of alive not leader threads that the process generating the event currently has. This excludes the leader thread. thread.cpu DOUBLE The CPU consumed by the thread in the last second. thread.cpu.user DOUBLE The user CPU consumed by the thread in the last second. thread.cpu.system DOUBLE The system CPU consumed by the thread in the last second. thread.vmsize UINT64 For the process main thread, this is the total virtual memory for the process (as kb). For the other threads, this field is zero. thread.vmrss UINT64 For the process main thread, this is the resident non-swapped memory for the process (as kb). For the other threads, this field is zero. proc.stdin.type CHARBUF The type of file descriptor 0, corresponding to stdin, of the process generating the event. proc.stdout.type CHARBUF The type of file descriptor 1, corresponding to stdout, of the process generating the event. proc.stderr.type CHARBUF The type of file descriptor 2, corresponding to stderr, of the process generating the event. proc.stdin.name CHARBUF The name of the file descriptor 0, corresponding to stdin, of the process generating the event. proc.stdout.name CHARBUF The name of the file descriptor 1, corresponding to stdout, of the process generating the event. proc.stderr.name CHARBUF The name of the file descriptor 2, corresponding to stderr, of the process generating the event. Field Class: user Information about the user executing the specific event.\nName Type Description user.uid UINT32 user ID. user.name CHARBUF user name. user.homedir CHARBUF home directory of the user. user.shell CHARBUF user's shell. user.loginuid INT64 audit user id (auid), internally the loginuid is of type uint32_t. However, if an invalid uid corresponding to UINT32_MAX is encountered, it is returned as -1 to support familiar filtering conditions. user.loginname CHARBUF audit user name (auid). Field Class: group Information about the user group.\nName Type Description group.gid UINT32 group ID. group.name CHARBUF group name. Field Class: fd Every syscall that has a file descriptor in its arguments has these fields set with information related to the file.\nName Type Description fd.num INT64 the unique number identifying the file descriptor. fd.type CHARBUF type of FD. Can be 'file', 'directory', 'ipv4', 'ipv6', 'unix', 'pipe', 'event', 'signalfd', 'eventpoll', 'inotify' 'signalfd' or 'memfd'. fd.typechar CHARBUF type of FD as a single character. Can be 'f' for file, 4 for IPv4 socket, 6 for IPv6 socket, 'u' for unix socket, p for pipe, 'e' for eventfd, 's' for signalfd, 'l' for eventpoll, 'i' for inotify, 'b' for bpf, 'u' for userfaultd, 'r' for io_uring, 'm' for memfd ,'o' for unknown. fd.name CHARBUF FD full name. If the fd is a file, this field contains the full path. If the FD is a socket, this field contain the connection tuple. fd.directory CHARBUF If the fd is a file, the directory that contains it. fd.filename CHARBUF If the fd is a file, the filename without the path. fd.ip IPADDR matches the ip address (client or server) of the fd. fd.cip IPADDR client IP address. fd.sip IPADDR server IP address. fd.lip IPADDR local IP address. fd.rip IPADDR remote IP address. fd.port PORT matches the port (either client or server) of the fd. fd.cport PORT for TCP/UDP FDs, the client port. fd.sport PORT for TCP/UDP FDs, server port. fd.lport PORT for TCP/UDP FDs, the local port. fd.rport PORT for TCP/UDP FDs, the remote port. fd.l4proto CHARBUF the IP protocol of a socket. Can be 'tcp', 'udp', 'icmp' or 'raw'. fd.sockfamily CHARBUF the socket family for socket events. Can be 'ip' or 'unix'. fd.is_server BOOL 'true' if the process owning this FD is the server endpoint in the connection. fd.uid CHARBUF a unique identifier for the FD, created by chaining the FD number and the thread ID. fd.containername CHARBUF chaining of the container ID and the FD name. Useful when trying to identify which container an FD belongs to. fd.containerdirectory CHARBUF chaining of the container ID and the directory name. Useful when trying to identify which container a directory belongs to. fd.proto PORT matches the protocol (either client or server) of the fd. fd.cproto CHARBUF for TCP/UDP FDs, the client protocol. fd.sproto CHARBUF for TCP/UDP FDs, server protocol. fd.lproto CHARBUF for TCP/UDP FDs, the local protocol. fd.rproto CHARBUF for TCP/UDP FDs, the remote protocol. fd.net IPNET matches the IP network (client or server) of the fd. fd.cnet IPNET matches the client IP network of the fd. fd.snet IPNET matches the server IP network of the fd. fd.lnet IPNET matches the local IP network of the fd. fd.rnet IPNET matches the remote IP network of the fd. fd.connected BOOL for TCP/UDP FDs, 'true' if the socket is connected. fd.name_changed BOOL True when an event changes the name of an fd used by this event. This can occur in some cases such as udp connections where the connection tuple changes. fd.cip.name CHARBUF Domain name associated with the client IP address. fd.sip.name CHARBUF Domain name associated with the server IP address. fd.lip.name CHARBUF Domain name associated with the local IP address. fd.rip.name CHARBUF Domain name associated with the remote IP address. fd.dev INT32 device number (major/minor) containing the referenced file fd.dev.major INT32 major device number containing the referenced file fd.dev.minor INT32 minor device number containing the referenced file fd.ino INT64 inode number of the referenced file fd.nameraw CHARBUF FD full name raw. Just like fd.name, but only used if fd is a file path. File path is kept raw with limited sanitization and without deriving the absolute path. fd.types LIST(CHARBUF) List of FD types in used. Can be passed an fd number e.g. fd.types[0] to get the type of stdout as a single item list. fd.is_upper_layer BOOL 'true' if the fd is of a file in the upper layer of an overlayfs. fd.is_lower_layer BOOL 'true' if the fd is of a file in the lower layer of an overlayfs. Field Class: fs.path Every syscall that has a filesystem path in its arguments has these fields set with information related to the path arguments. This differs from the fd.* fields as it includes syscalls like unlink, rename, etc. that act directly on filesystem paths as compared to opened file descriptors.\nName Type Description fs.path.name CHARBUF For any event type that deals with a filesystem path, the path the file syscall is operating on. This path is always fully resolved, prepending the thread cwd when needed. fs.path.nameraw CHARBUF For any event type that deals with a filesystem path, the path the file syscall is operating on. This path is always the path provided to the syscall and may not be fully resolved. fs.path.source CHARBUF For any event type that deals with a filesystem path, and specifically for a source and target like mv, cp, etc, the source path the file syscall is operating on. This path is always fully resolved, prepending the thread cwd when needed. fs.path.sourceraw CHARBUF For any event type that deals with a filesystem path, and specifically for a source and target like mv, cp, etc, the source path the file syscall is operating on. This path is always the path provided to the syscall and may not be fully resolved. fs.path.target CHARBUF For any event type that deals with a filesystem path, and specifically for a target and target like mv, cp, etc, the target path the file syscall is operating on. This path is always fully resolved, prepending the thread cwd when needed. fs.path.targetraw CHARBUF For any event type that deals with a filesystem path, and specifically for a target and target like mv, cp, etc, the target path the file syscall is operating on. This path is always the path provided to the syscall and may not be fully resolved. Field Class: fdlist Poll event related fields.\nName Type Description fdlist.nums CHARBUF for poll events, this is a comma-separated list of the FD numbers in the 'fds' argument, returned as a string. fdlist.names CHARBUF for poll events, this is a comma-separated list of the FD names in the 'fds' argument, returned as a string. fdlist.cips CHARBUF for poll events, this is a comma-separated list of the client IP addresses in the 'fds' argument, returned as a string. fdlist.sips CHARBUF for poll events, this is a comma-separated list of the server IP addresses in the 'fds' argument, returned as a string. fdlist.cports CHARBUF for TCP/UDP FDs, for poll events, this is a comma-separated list of the client TCP/UDP ports in the 'fds' argument, returned as a string. fdlist.sports CHARBUF for poll events, this is a comma-separated list of the server TCP/UDP ports in the 'fds' argument, returned as a string. Field Class: container (plugin) Name Type Description container.id CHARBUF The truncated container ID (first 12 characters), e.g. 3ad7b26ded6d is extracted from the Linux cgroups by Falco within the kernel. Consequently, this field is reliably available and serves as the lookup key for Falco's synchronous or asynchronous requests against the container runtime socket to retrieve all other 'container.' information. One important aspect to be aware of is that if the process occurs on the host, meaning not in the container PID namespace, this field is set to a string called 'host'. In Kubernetes, pod sandbox container processes can exist where container.id matches k8s.pod.sandbox_id, lacking other 'container.' details. container.full_id CHARBUF The full container ID, e.g. 3ad7b26ded6d8e7b23da7d48fe889434573036c27ae5a74837233de441c3601e. In contrast to container.id, we enrich this field as part of the container engine enrichment. In instances of userspace container engine lookup delays, this field may not be available yet. container.name CHARBUF The container name. In instances of userspace container engine lookup delays, this field may not be available yet. One important aspect to be aware of is that if the process occurs on the host, meaning not in the container PID namespace, this field is set to a string called 'host'. container.image CHARBUF The container image name (e.g. falcosecurity/falco:latest for docker). In instances of userspace container engine lookup delays, this field may not be available yet. container.image.id CHARBUF The container image id (e.g. 6f7e2741b66b). In instances of userspace container engine lookup delays, this field may not be available yet. container.type CHARBUF The container type, e.g. docker, cri-o, containerd etc. container.privileged BOOL 'true' for containers running as privileged, 'false' otherwise. In instances of userspace container engine lookup delays, this field may not be available yet. container.mounts CHARBUF A space-separated list of mount information. Each item in the list has the format 'source:dest:mode:rdrw:propagation'. In instances of userspace container engine lookup delays, this field may not be available yet. container.mount CHARBUF Information about a single mount, specified by number (e.g. container.mount[0]) or mount source (container.mount[/usr/local]). The pathname can be a glob (container.mount[/usr/local/*]), in which case the first matching mount will be returned. The information has the format 'source:dest:mode:rdrw:propagation'. If there is no mount with the specified index or matching the provided source, returns the string \u0026quot;none\u0026quot; instead of a NULL value. In instances of userspace container engine lookup delays, this field may not be available yet. container.mount.source CHARBUF The mount source, specified by number (e.g. container.mount.source[0]) or mount destination (container.mount.source[/host/lib/modules]). The pathname can be a glob. In instances of userspace container engine lookup delays, this field may not be available yet. container.mount.dest CHARBUF The mount destination, specified by number (e.g. container.mount.dest[0]) or mount source (container.mount.dest[/lib/modules]). The pathname can be a glob. In instances of userspace container engine lookup delays, this field may not be available yet. container.mount.mode CHARBUF The mount mode, specified by number (e.g. container.mount.mode[0]) or mount source (container.mount.mode[/usr/local]). The pathname can be a glob. In instances of userspace container engine lookup delays, this field may not be available yet. container.mount.rdwr CHARBUF The mount rdwr value, specified by number (e.g. container.mount.rdwr[0]) or mount source (container.mount.rdwr[/usr/local]). The pathname can be a glob. In instances of userspace container engine lookup delays, this field may not be available yet. container.mount.propagation CHARBUF The mount propagation value, specified by number (e.g. container.mount.propagation[0]) or mount source (container.mount.propagation[/usr/local]). The pathname can be a glob. In instances of userspace container engine lookup delays, this field may not be available yet. container.image.repository CHARBUF The container image repository (e.g. falcosecurity/falco). In instances of userspace container engine lookup delays, this field may not be available yet. container.image.tag CHARBUF The container image tag (e.g. stable, latest). In instances of userspace container engine lookup delays, this field may not be available yet. container.image.digest CHARBUF The container image registry digest (e.g. sha256:d977378f890d445c15e51795296e4e5062f109ce6da83e0a355fc4ad8699d27). In instances of userspace container engine lookup delays, this field may not be available yet. container.healthcheck CHARBUF The container's health check. Will be the null value (\u0026quot;N/A\u0026quot;) if no healthcheck configured, \u0026quot;NONE\u0026quot; if configured but explicitly not created, and the healthcheck command line otherwise. In instances of userspace container engine lookup delays, this field may not be available yet. container.liveness_probe CHARBUF The container's liveness probe. Will be the null value (\u0026quot;N/A\u0026quot;) if no liveness probe configured, the liveness probe command line otherwise. In instances of userspace container engine lookup delays, this field may not be available yet. container.readiness_probe CHARBUF The container's readiness probe. Will be the null value (\u0026quot;N/A\u0026quot;) if no readiness probe configured, the readiness probe command line otherwise. In instances of userspace container engine lookup delays, this field may not be available yet. container.start_ts ABSTIME Container start as epoch timestamp in nanoseconds based on proc.pidns_init_start_ts and extracted in the kernel and not from the container runtime socket / container engine. container.duration RELTIME Number of nanoseconds since container.start_ts. container.ip CHARBUF The container's / pod's primary ip address as retrieved from the container engine. Only ipv4 addresses are tracked. Consider container.cni.json (CRI use case) for logging ip addresses for each network interface. In instances of userspace container engine lookup delays, this field may not be available yet. container.cni.json CHARBUF The container's / pod's CNI result field from the respective pod status info. It contains ip addresses for each network interface exposed as unparsed escaped JSON string. Supported for CRI container engine (containerd, cri-o runtimes), optimized for containerd (some non-critical JSON keys removed). Useful for tracking ips (ipv4 and ipv6, dual-stack support) for each network interface (multi-interface support). In instances of userspace container engine lookup delays, this field may not be available yet. container.host_pid BOOL 'true' if the container is running in the host PID namespace, 'false' otherwise. container.host_network BOOL 'true' if the container is running in the host network namespace, 'false' otherwise. container.host_ipc BOOL 'true' if the container is running in the host IPC namespace, 'false' otherwise. container.label CHARBUF Container label. E.g. 'container.label.foo'. container.labels CHARBUF Container comma-separated key/value labels. E.g. 'foo1:bar1,foo2:bar2'. proc.is_container_healthcheck BOOL 'true' if this process is running as a part of the container's health check. proc.is_container_liveness_probe BOOL 'true' if this process is running as a part of the container's liveness probe. proc.is_container_readiness_probe BOOL 'true' if this process is running as a part of the container's readiness probe. k8s.pod.name CHARBUF The Kubernetes pod name. This field is extracted from the container runtime socket simultaneously as we look up the 'container.*' fields. In cases of lookup delays, it may not be available yet. k8s.ns.name CHARBUF The Kubernetes namespace name. This field is extracted from the container runtime socket simultaneously as we look up the 'container.*' fields. In cases of lookup delays, it may not be available yet. k8s.pod.id CHARBUF [LEGACY] The Kubernetes pod UID, e.g. 3e41dc6b-08a8-44db-bc2a-3724b18ab19a. This legacy field points to k8s.pod.uid; however, the pod ID typically refers to the pod sandbox ID. We recommend using the semantically more accurate k8s.pod.uid field. This field is extracted from the container runtime socket simultaneously as we look up the 'container.*' fields. In cases of lookup delays, it may not be available yet. k8s.pod.uid CHARBUF The Kubernetes pod UID, e.g. 3e41dc6b-08a8-44db-bc2a-3724b18ab19a. Note that the pod UID is a unique identifier assigned upon pod creation within Kubernetes, allowing the Kubernetes control plane to manage and track pods reliably. As such, it is fundamentally a different concept compared to the pod sandbox ID. This field is extracted from the container runtime socket simultaneously as we look up the 'container.*' fields. In cases of lookup delays, it may not be available yet. k8s.pod.sandbox_id CHARBUF The truncated Kubernetes pod sandbox ID (first 12 characters), e.g 63060edc2d3a. The sandbox ID is specific to the container runtime environment. It is the equivalent of the container ID for the pod / sandbox and extracted from the Linux cgroups. As such, it differs from the pod UID. This field is extracted from the container runtime socket simultaneously as we look up the 'container.' fields. In cases of lookup delays, it may not be available yet. In Kubernetes, pod sandbox container processes can exist where container.id matches k8s.pod.sandbox_id, lacking other 'container.' details. k8s.pod.full_sandbox_id CHARBUF The full Kubernetes pod / sandbox ID, e.g 63060edc2d3aa803ab559f2393776b151f99fc5b05035b21db66b3b62246ad6a. This field is extracted from the container runtime socket simultaneously as we look up the 'container.*' fields. In cases of lookup delays, it may not be available yet. k8s.pod.label CHARBUF The Kubernetes pod label. The label can be accessed either with the familiar brackets notation, e.g. 'k8s.pod.label[foo]' or by appending a dot followed by the name, e.g. 'k8s.pod.label.foo'. The label name itself can include the original special characters such as '.', '-', '_' or '/' characters. For instance, 'k8s.pod.label[app.kubernetes.io/name]', 'k8s.pod.label.app.kubernetes.io/name' or 'k8s.pod.label[custom-label_one]' are all valid. This field is extracted from the container runtime socket simultaneously as we look up the 'container.*' fields. In cases of lookup delays, it may not be available yet. k8s.pod.labels CHARBUF The Kubernetes pod comma-separated key/value labels. E.g. 'foo1:bar1,foo2:bar2'. This field is extracted from the container runtime socket simultaneously as we look up the 'container.*' fields. In cases of lookup delays, it may not be available yet. k8s.pod.ip CHARBUF The Kubernetes pod ip, same as container.ip field as each container in a pod shares the network stack of the sandbox / pod. Only ipv4 addresses are tracked. Consider k8s.pod.cni.json for logging ip addresses for each network interface. This field is extracted from the container runtime socket simultaneously as we look up the 'container.*' fields. In cases of lookup delays, it may not be available yet. k8s.pod.cni.json CHARBUF The Kubernetes pod CNI result field from the respective pod status info, same as container.cni.json field. It contains ip addresses for each network interface exposed as unparsed escaped JSON string. Supported for CRI container engine (containerd, cri-o runtimes), optimized for containerd (some non-critical JSON keys removed). Useful for tracking ips (ipv4 and ipv6, dual-stack support) for each network interface (multi-interface support). This field is extracted from the container runtime socket simultaneously as we look up the 'container.*' fields. In cases of lookup delays, it may not be available yet. k8s.rc.name CHARBUF Deprecated. Use k8smeta plugin instead. k8s.rc.id CHARBUF Deprecated. Use k8smeta plugin instead. k8s.rc.label CHARBUF Deprecated. Use k8smeta plugin instead. k8s.rc.labels CHARBUF Deprecated. Use k8smeta plugin instead. k8s.svc.name CHARBUF Deprecated. Use k8smeta plugin instead. k8s.svc.id CHARBUF Deprecated. Use k8smeta plugin instead. k8s.svc.label CHARBUF Deprecated. Use k8smeta plugin instead. k8s.svc.labels CHARBUF Deprecated. Use k8smeta plugin instead. k8s.ns.id CHARBUF Deprecated. Use k8smeta plugin instead. k8s.ns.label CHARBUF Deprecated. Use k8smeta plugin instead. k8s.ns.labels CHARBUF Deprecated. Use k8smeta plugin instead. k8s.rs.name CHARBUF Deprecated. Use k8smeta plugin instead. k8s.rs.id CHARBUF Deprecated. Use k8smeta plugin instead. k8s.rs.label CHARBUF Deprecated. Use k8smeta plugin instead. k8s.rs.labels CHARBUF Deprecated. Use k8smeta plugin instead. k8s.deployment.name CHARBUF Deprecated. Use k8smeta plugin instead. k8s.deployment.id CHARBUF Deprecated. Use k8smeta plugin instead. k8s.deployment.label CHARBUF Deprecated. Use k8smeta plugin instead. k8s.deployment.labels CHARBUF Deprecated. Use k8smeta plugin instead. ","summary":"","tags":null,"title":"Supported Fields for Conditions and Outputs","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/rules/supported-fields/"},{"category":"docs","content":"Introduction With the enhancements introduced in v0.15.0, Falco can now intelligently detect dropped system call events and take remedial actions, such as alerting or even exiting Falco entirely. When system call events are dropped, Falco might encounter problems building its internal view of the processes, files, containers, and orchestrator metadata in use, which in turn might affect the rules that depend on that metadata. The explicit signals that Falco now provides make it easier to detect dropped system calls.\nFor more information on this feature, see our blog post on CVE-2019-8339.\nImplementation Every second, Falco reads system call event counts that are populated by the kernel module/eBPF program. The reading includes the number of system calls processed, and most importantly, the number of times the kernel tried to write system call information to the shared buffer between the kernel and user space, but found the buffer was full. These failed write attempts are considered dropped system call events.\nWhen at least one dropped event is detected, Falco takes one of the following actions:\nignore: no action is taken. If an empty list is provided, ignore is assumed. log: log a CRITICAL message noting that the buffer was full. alert: emit a Falco alert stating that the buffer was full. exit: exit Falco with a non-zero rc. Given below are a sample log message, an alert, and an exit message:\nWed Mar 27 15:28:22 2019: Falco initialized with configuration file /etc/falco/falco.yaml Wed Mar 27 15:28:22 2019: Loading rules from file /etc/falco/falco_rules.yaml: Wed Mar 27 15:28:24 2019: Falco internal: syscall event drop. 1 system calls dropped in last second. 15:28:24.000207862: Critical Falco internal: syscall event drop. 1 system calls dropped in last second.(n_drops=1 n_evts=1181) Wed Mar 27 15:28:24 2019: Falco internal: syscall event drop. 1 system calls dropped in last second. Wed Mar 27 15:28:24 2019: Exiting. Actions Rate Throttling To reduce the likelihood of a flood of log messages/alerts, Falco provides an alert throttling mechanism disabled by default. This feature can be enabled through the Falco configuration (see the outputs entry).\nBefore \u0026lt;a href=\u0026quot;/blog/falco-0-33-0/\u0026quot;\u0026gt;v0.33.0\u0026lt;/a\u0026gt; this feature was enabled by default. Configuration The actions to take on a dropped system call event and the throttling parameters for the token bucket are configurable in the file falco.yaml. You can find them in syscall_event_drops.\n","summary":"","tags":null,"title":"Actions For Dropped System Call Events","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/event-sources/kernel/dropped-events/"},{"category":"docs","content":"You can find below the officially registered plugins, more details on https://github.com/falcosecurity/plugins.\nID Plugin Type Source Description Authors URL Rules URL Licence \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 1 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;k8saudit\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; k8s_audit \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Read Kubernetes Audit Events and monitor Kubernetes Clusters \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8saudit\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8saudit/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 2 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;cloudtrail\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; aws_cloudtrail \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Reads Cloudtrail JSON logs from files/S3 and injects as events \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/cloudtrail\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/cloudtrail/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; - \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;json\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; extraction \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Extract values from any JSON payload \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/json\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 3 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;dummy\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; dummy \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Reference plugin used to document interface \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/dummy\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 4 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;dummy_c\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; dummy_c \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Like dummy, but written in C\u0026amp;#43;\u0026amp;#43; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/dummy_c\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 5 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;docker\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; docker \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Docker Events \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/Issif\u0026quot;\u0026gt;Thomas Labarussias\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/Issif/docker-plugin\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/Issif/docker-plugin/tree/main/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 6 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;seccompagent\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; seccompagent \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Seccomp Agent Events \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/kinvolk/seccompagent\u0026quot;\u0026gt;Alban Crequy\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/kinvolk/seccompagent\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 7 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;okta\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; okta \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Okta Log Events \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/okta\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/okta/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 8 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;github\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; github \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Github Webhook Events \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/github\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/github/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 9 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;k8saudit-eks\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; k8s_audit \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Read Kubernetes Audit Events from AWS EKS Clusters \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8saudit-eks\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8saudit/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 10 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;nomad\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; nomad \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Read Hashicorp Nomad Events Stream \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/albertollamaso/nomad-plugin/issues\u0026quot;\u0026gt;Alberto Llamas\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/albertollamaso/nomad-plugin/tree/main\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/albertollamaso/nomad-plugin/tree/main/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 11 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;dnscollector\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; dnscollector \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; DNS Collector Events \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/SysdigDan/dnscollector-falco-plugin/issues\u0026quot;\u0026gt;Daniel Moloney\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/SysdigDan/dnscollector-falco-plugin\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/SysdigDan/dnscollector-falco-plugin/tree/master/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 12 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;gcpaudit\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; gcp_auditlog \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Read GCP Audit Logs \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/gcpaudit\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/gcpaudit/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 13 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;syslogsrv\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; syslogsrv \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Syslog Server Events \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/nabokihms/syslogsrv-falco-plugin/issues\u0026quot;\u0026gt;Maksim Nabokikh\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/nabokihms/syslogsrv-falco-plugin/tree/main/plugins/syslogsrv\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/nabokihms/syslogsrv-falco-plugin/tree/main/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 14 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;salesforce\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; salesforce \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Falco plugin providing basic runtime threat detection and auditing logging for Salesforce \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/an1245/falco-plugin-salesforce/issues\u0026quot;\u0026gt;Andy\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/an1245/falco-plugin-salesforce/\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/an1245/falco-plugin-salesforce/tree/main/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 15 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;box\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; box \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Falco plugin providing basic runtime threat detection and auditing logging for Box \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/an1245/falco-plugin-box/issues\u0026quot;\u0026gt;Andy\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/an1245/falco-plugin-box/\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/an1245/falco-plugin-box/tree/main/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; - \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;k8smeta\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; extraction \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Enriche Falco syscall flow with Kubernetes Metadata \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8smeta\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 16 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;k8saudit-gke\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; k8s_audit \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Read Kubernetes Audit Events from GKE Clusters \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8saudit-gke\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8saudit-gke/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 17 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;journald\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; journal \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Read Journald events into Falco \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/gnosek/falco-journald-plugin\u0026quot;\u0026gt;Grzegorz Nosek\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/gnosek/falco-journald-plugin\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 18 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;kafka\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; kafka \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Read events from Kafka topics into Falco \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;Hunter Madison\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/kafka\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/kafka/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 19 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;gitlab\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; gitlab \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Falco plugin providing basic runtime threat detection and auditing logging for GitLab \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/an1245/falco-plugin-gitlab/issues\u0026quot;\u0026gt;Andy\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/an1245/falco-plugin-gitlab\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/an1245/falco-plugin-gitlab/tree/main/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 20 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;keycloak\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; keycloak \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Falco plugin for sourcing and extracting Keycloak user/admin events \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/mattiaforc/falco-keycloak-plugin/issues\u0026quot;\u0026gt;Mattia Forcellese\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/mattiaforc/falco-keycloak-plugin\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/mattiaforc/falco-keycloak-plugin/tree/main/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 21 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;k8saudit-aks\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; k8s_audit \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Read Kubernetes Audit Events from Azure AKS Clusters \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8saudit-aks\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8saudit/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 22 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;k8saudit-ovh\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; k8s_audit \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Read Kubernetes Audit Events from OVHcloud MKS Clusters \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;Aurélie Vache\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8saudit-ovh\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/k8saudit/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 23 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;dummy_rs\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; dummy_rs \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Like dummy, but written in Rust \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/dummy_rs\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; - \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;container\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; extraction \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Enriche Falco syscall flow with Container Metadata \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/container\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; - \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;krsi\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; extraction \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Security (KRSI) events support for Falco \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/krsi\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 24 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;collector\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; collector \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Generic collector to ingest raw payloads into Falco \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://falco.org/community\u0026quot;\u0026gt;The Falco Authors\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/falcosecurity/plugins/tree/main/plugins/collector\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 25 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;awselb\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; awselb \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; AWS Elastic Load Balancer access logs events \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/yukinakanaka/falco-plugin-aws-elb/issues\u0026quot;\u0026gt;Yuki Nakamura\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/yukinakanaka/falco-plugin-aws-elb\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/yukinakanaka/falco-plugin-aws-elb/tree/main/rules\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 26 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;edera\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; edera_zone \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; A Falco plugin for forwarding libscap events out of Edera zones. \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;contact@edera.dev\u0026quot;\u0026gt;Edera\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://github.com/edera-dev/falco_plugin/\u0026quot;\u0026gt;🔗\u0026lt;/a\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;a href=\u0026quot;https://docs.edera.dev/guides/observability/falco-integration/\u0026quot;\u0026gt;🔗 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Apache-2.0 \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 27 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;nginx\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; nginx \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Real-time nginx access log monitoring for security threats. Detects SQL injection, XSS, path traversal, command injection, brute force attacks, and OWASP Top 10 vulnerabilities.\ntakaosgb3 🔗 🔗 Apache-2.0 \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt; 28 \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;b\u0026gt;coding_agent\u0026lt;/b\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; sourcing \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;span class=\u0026quot;source\u0026quot;\u0026gt; coding_agent \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; Runtime detection for AI coding agents with Falco (part of the Prempti project). Intercepts tool calls (shell commands, file operations, web fetches, MCP calls) before they run and produces allow/deny/ask verdicts via customizable Falco rules, with a full audit trail of agent activity.\nThe Falco Authors 🔗 🔗 Apache-2.0 ","summary":"","tags":null,"title":"Registered Plugins","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/plugins/registered-plugins/"},{"category":"docs","content":"Overview There may be cases where you need to adjust the behavior of the Falco-supplied list, macro, and rule.\nYou can override (modify) rules in Falco two different ways:\nDefine multiple rules files. The additional rules files can be used to add new lists, macros and rules or to override existing ones. You can override lists, macros, and rules in the same file so long as the override happens after the initial definition. \u0026lt;p\u0026gt;Note that when overriding existing lists, macro, or rule the order of the rule configuration files matters. For example if you append to an existing default rule, you must ensure your custom rules file (e.g. \u0026lt;code\u0026gt;/etc/falco/rules.d/custom-rules.yaml\u0026lt;/code\u0026gt;) is loaded \u0026lt;strong\u0026gt;after\u0026lt;/strong\u0026gt; the default rules file (\u0026lt;code\u0026gt;/etc/falco/falco_rules.yaml\u0026lt;/code\u0026gt;).\u0026lt;/p\u0026gt; The load order can be configured from the command line using multiple -r parameters in the right order, directly inside the Falco configuration file (falco.yaml) via the rules_files section or through the official Helm chart, using the falco.rules_files value.\nTo facilitate modifying existing lists, macros and rules Falco provides an override section that can be added to your custom rules file. Within the override section you can specify whether you want to append or replace information for the given rule, list or macro.\nappend allows you to add additional values to a list, macro, or rule key\nreplace allows you to replace the value of a list, macro or macro key\n\u0026lt;code\u0026gt;append\u0026lt;/code\u0026gt; and \u0026lt;code\u0026gt;replace\u0026lt;/code\u0026gt; cannot be used together. Trying to apply both will result in an error. The keys that can be overridden vary by rules component and action being taken:\nLists (append or replace): items Macros (append or replace): condition Rules (append): condition, output, desc, tags, exceptions Rules (replace): condition, output desc, priority, tags, exceptions, enabled, warn_evttypes, skip-if-unknown-filter Examples of using the override section The following examples illustrate how you can use the override section to modify existing lists, macros, and rules.\nIn all the examples below, it's assumed one is running Falco via falco -r /etc/falco/falco_rules.yaml -r /etc/falco/falco_rules.local.yaml, or has the default entries for rules_files in falco.yaml, which has /etc/falco/falco.yaml first and /etc/falco/falco_rules.local.yaml second.\nAppend an item to a list /etc/falco/falco_rules.yaml - list: my_programs items: [ls, cat, pwd] - rule: my_programs_opened_file desc: Track whenever a set of programs opens a file condition: proc.name in (my_programs) and (evt.type=open or evt.type=openat) output: A tracked program opened a file | user=%user.name command=%proc.cmdline file=%fd.name priority: INFO /etc/falco/falco_rules.local.yaml - list: my_programs items: [cp] override: items: append The rule my_programs_opened_file would trigger whenever any of ls, cat, pwd, or cp opened a file.\nReplace items in a list /etc/falco/falco_rules.yaml - list: my_programs items: [ls, cat, pwd] - rule: my_programs_opened_file desc: Track whenever a set of programs opens a file condition: proc.name in (my_programs) and (evt.type=open or evt.type=openat) output: A tracked program opened a file | user=%user.name command=%proc.cmdline file=%fd.name priority: INFO /etc/falco/falco_rules.local.yaml - list: my_programs items: [vi, vim, nano] override: items: replace The rule my_programs_opened_file would trigger whenever any of vi, vim, or nano opened a file.\nAppend an item to a macro /etc/falco/falco_rules.yaml - macro: access_file condition: evt.type=open - rule: program_accesses_file desc: Track whenever a set of programs opens a file condition: (access_file) and proc.name in (cat, ls) output: A tracked program opened a file | user=%user.name command=%proc.cmdline file=%fd.name priority: INFO /etc/falco/falco_rules.local.yaml - macro: access_file condition: or evt.type=openat override: condition: append The rule program_accesses_file would trigger when ls/cat either used open/openat on a file.\nAppend and replace items in a rule /etc/falco/falco_rules.yaml - rule: program_accesses_file desc: Yrack whenever a set of programs opens a file condition: evt.type=open and proc.name in (cat, ls) output: A tracked program opened a file | user=%user.name command=%proc.cmdline file=%fd.name priority: INFO /etc/falco/falco_rules.local.yaml - rule: program_accesses_file condition: and not user.name=root output: A file (user=%user.name command=%proc.cmdline file=%fd.name) was opened by a monitored program override: condition: append output: replace The rule program_accesses_file would trigger when ls/cat either used open on a file, but not if the user was root.\nThe new output message would be A file (user=%user.name command=%proc.cmdline file=%fd.name) was opened by a monitored program\nEnabling a disabled rule Using enabled: true is deprecated, and should be avoided. Falco 0.37.0 and later will display a warning if enabled: true is used.\n/etc/falco/falco_rules.yaml - rule: test_rule desc: test rule description condition: evt.type = close output: user=%user.name command=%proc.cmdline file=%fd.name priority: INFO enabled: false /etc/falco/falco_rules.local.yaml (incorrect usage example) - rule: test_rule enabled: true Use the new override section to enable the rule instead.\n/etc/falco/falco_rules.yaml - rule: test_rule desc: test rule description condition: evt.type = close output: user=%user.name command=%proc.cmdline file=%fd.name priority: INFO enabled: false /etc/falco/falco_rules.local.yaml (correct usage example) - rule: test_rule enabled: true override: enabled: replace Precedence of logical operators when appending Remember that when appending rules and macros, the content of the referring rule or macro is simply added to the condition of the referred one. This can result in unintended results if the original rule/macro has potentially ambiguous logical operators.\nHere's an example:\n- rule: my_rule desc: ... condition: evt.type=open and proc.name=apache output: ... - rule: my_rule append: true condition: or proc.name=nginx Should proc.name=nginx be interpreted as relative to the and proc.name=apache, that is to allow either apache/nginx to open files, or relative to the evt.type=open, that is to allow apache to open files or to allow nginx to do anything?\nIn cases like this, be sure to scope the logical operators of the original condition with parentheses when possible, or avoid appending conditions when not possible.\nAppending to existing rules using append key (deprecated) The append key has been deprecated and will be removed in Falco 1.0.0. Use the override section instead.\nIf you use multiple Falco rules files, you might want to append new items to an existing lists, macros or rules. To do that, define an item with the same name as an existing item and add an append: true attribute to the YAML object.\nWhen appending to lists, items are automatically added to the \u0026lt;strong\u0026gt;end\u0026lt;/strong\u0026gt; of the \u0026lt;em\u0026gt;list\u0026lt;/em\u0026gt;.\u0026lt;br\u0026gt; When appending to rules or macros, the additional content is appended to the condition field of the referred object.\nNote that when appending to lists, rules or macros, the order of the rule configuration files matters! For example if you append to an existing default rule (e.g. Terminal shell in container), you must ensure your custom configuration file (e.g. /etc/falco/rules.d/custom-rules.yaml) is loaded after the default configuration file (/etc/falco/falco_rules.yaml).\nThis can be configured with multiple -r parameters in the right order, directly inside the Falco configuration file (falco.yaml) via rules_files or if you use the official Helm chart, via the falco.rules_files value.\nRedefining existing rules using append key (deprecated) The append key has been deprecated and will be removed in Falco 1.0.0. Use the override section instead.\nIf append is set to false (default value), the whole object will be redefined. This can be used to empty a list, apply user-specific settings to a macro or even change a rule completely.\nTake into account that when redefining a rule, it will entirely replace the previous rule, so if the new object defines fewer fields than required, Falco could return an error.\nThe only exceptions to this are the enabled field, that when defined as a single accompanying field, it simply enables or disables a previously-defined rule. And obviously, the append field, that when set to true for either macros or rules, it just appends the condition/exceptions field.\nExamples of appending using append key (deprecated) The append key has been deprecated and will be removed in Falco 1.0.0. Use the override section instead.\nIn all the examples below, it's assumed one is running Falco via falco -r /etc/falco/falco_rules.yaml -r /etc/falco/falco_rules.local.yaml, or has the default entries for rules_files in falco.yaml, which has /etc/falco/falco.yaml first and /etc/falco/falco_rules.local.yaml second.\nAppending to Lists Here's an example of appending to lists:\n/etc/falco/falco_rules.yaml - list: my_programs items: [ls, cat, pwd] - rule: my_programs_opened_file desc: Track whenever a set of programs opens a file condition: proc.name in (my_programs) and (evt.type=open or evt.type=openat) output: A tracked program opened a file | user=%user.name command=%proc.cmdline file=%fd.name priority: INFO /etc/falco/falco_rules.local.yaml - list: my_programs append: true items: [cp] The rule my_programs_opened_file would trigger whenever any of ls, cat, pwd, or cp opened a file.\nAppending to Macros Here's an example of appending to macros:\n/etc/falco/falco_rules.yaml - macro: access_file condition: evt.type=open - rule: program_accesses_file desc: Track whenever a set of programs opens a file condition: proc.name in (cat, ls) and (access_file) output: A tracked program opened a file | user=%user.name command=%proc.cmdline file=%fd.name priority: INFO /etc/falco/falco_rules.local.yaml - macro: access_file append: true condition: or evt.type=openat The rule program_accesses_file would trigger when ls/cat either used open/openat on a file.\nAppending to Rules Here's an example of appending to rules:\n/etc/falco/falco_rules.yaml - rule: program_accesses_file desc: track whenever a set of programs opens a file condition: proc.name in (cat, ls) and evt.type=open output: A tracked program opened a file | user=%user.name command=%proc.cmdline file=%fd.name priority: INFO /etc/falco/falco_rules.local.yaml - rule: program_accesses_file append: true condition: and not user.name=root The rule program_accesses_file would trigger when ls/cat either used open on a file, but not if the user was root.\nAppend Exceptions to Rules It is also possible to append exceptions to rules.\u0026lt;br\u0026gt; Here you can find further information.\n","summary":"","tags":null,"title":"Overriding Rules","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/overriding/"},{"category":"docs","content":"The Falco Okta plugin can read Okta logs and emit events for each Okta log entry.\nFalco also distributes out-of-the-box rules that can be used to identify interesting/suspicious/notable events in Okta logs, including:\nCreating a new OKTA user account Detecting a locked-out user Assigning admin permissions to an okta user Configuration See the README for information on configuring the plugin. This simply involves providing the organization/api token as part of init params. These can be added to falco.yaml under the plugins configuration key key.\nThe plugin does not use any open params configuration.\nSample Output For example, when using a dummy rule as follows:\n- rule: Dummy desc: Dummy condition: okta.app!=\u0026#34;\u0026#34; output: \u0026#34;evt=%okta.evt.type user=%okta.actor.name ip=%okta.client.ip app=%okta.app\u0026#34; priority: DEBUG source: okta tags: [okta] The dummy rule will emit an alert for each Okta log entry, like the following:\n19:12:25.439350000: Debug evt=user.authentication.sso user=User1 ip=x.x.x.x app=google 19:12:30.675628000: Debug evt=user.authentication.sso user=User2 ip=x.x.x.x app=github 19:12:35.918456000: Debug evt=user.authentication.sso user=User3 ip=x.x.x.x app=office365 ","summary":"","tags":null,"title":"Okta Events","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/event-sources/plugins/okta/"},{"category":"docs","content":" The gRPC Output as well as the embedded gRPC server have been deprecated in Falco 0.43.0 and will be removed in a future release. Until removal and since Falco 0.43.0, using any of them will result in a warning informing the user about the deprecation. Users are encouraged to leverage another output and/or Falcosidekick, as the usage will result in an error after the removal.\nThe client-go Go library provides:\ntype and service mappings for the Falco gRPC API. For more information, see output schema. Client and Config structs that simplify the connection to the gRPC server. For more information, see documentation. Refer to the fully-functional example to see how the Go client connects to the Falco gRPC Outputs API and displays the events in JSON.\nAdditional examples for various APIs are located in the examples directory of the client-go repository.\nEnsure that you have the certificates in the example's path at /etc/falco/certs/{client.crt,client.key,ca.crt}.\nIn the client-go root directory, run:\n$ go run examples/output/main.go | jq The output events start flowing in depending on the set of rules in the Falco instance.\n{ \u0026#34;time\u0026#34;: { \u0026#34;seconds\u0026#34;: 1570094449, \u0026#34;nanos\u0026#34;: 259268899 }, \u0026#34;priority\u0026#34;: 3, \u0026#34;rule\u0026#34;: \u0026#34;Modify binary dirs\u0026#34;, \u0026#34;output\u0026#34;: \u0026#34;09:20:49.259268899: Error File below known binary directory renamed/removed (user=vagrant command=lua /home/vagrant/.dotfiles/zsh/.config/zsh/plugins/z.lua/z.lua --init zsh once enhanced pcmdline=zsh operation=rena me file=\u0026lt;NA\u0026gt; res=0 oldpath=/usr/bin/realpath newpath=/usr/bin/realpath container_id=host image=\u0026lt;NA\u0026gt;)\u0026#34;, \u0026#34;output_fields\u0026#34;: { \u0026#34;container.id\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;container.image.repository\u0026#34;: \u0026#34;\u0026lt;NA\u0026gt;\u0026#34;, \u0026#34;evt.args\u0026#34;: \u0026#34;res=0 oldpath=/usr/bin/realpath newpath=/usr/bin/realpath \u0026#34;, \u0026#34;evt.time\u0026#34;: \u0026#34;09:20:49.259268899\u0026#34;, \u0026#34;evt.type\u0026#34;: \u0026#34;rename\u0026#34;, \u0026#34;fd.name\u0026#34;: \u0026#34;\u0026lt;NA\u0026gt;\u0026#34;, \u0026#34;proc.cmdline\u0026#34;: \u0026#34;lua /home/vagrant/.dotfiles/zsh/.config/zsh/plugins/z.lua/z.lua --init zsh once enhanced\u0026#34;, \u0026#34;proc.pcmdline\u0026#34;: \u0026#34;zsh\u0026#34;, \u0026#34;user.name\u0026#34;: \u0026#34;vagrant\u0026#34; } } { \u0026#34;time\u0026#34;: { \u0026#34;seconds\u0026#34;: 1570094449, \u0026#34;nanos\u0026#34;: 620298462 }, \u0026#34;priority\u0026#34;: 4, \u0026#34;rule\u0026#34;: \u0026#34;Delete or rename shell history\u0026#34;, \u0026#34;output\u0026#34;: \u0026#34;09:20:49.620298462: Warning Shell history had been deleted or renamed (user=vagrant type=unlink command=zsh fd.name=\u0026lt;NA\u0026gt; name=\u0026lt;NA\u0026gt; path=/home/vagrant/.zsh_history.LOCK oldpath=\u0026lt;NA\u0026gt; host (id=host))\u0026#34;, \u0026#34;output_fields\u0026#34;: { \u0026#34;container.id\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;container.name\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;evt.arg.name\u0026#34;: \u0026#34;\u0026lt;NA\u0026gt;\u0026#34;, \u0026#34;evt.arg.oldpath\u0026#34;: \u0026#34;\u0026lt;NA\u0026gt;\u0026#34;, \u0026#34;evt.arg.path\u0026#34;: \u0026#34;/home/vagrant/.zsh_history.LOCK\u0026#34;, \u0026#34;evt.time\u0026#34;: \u0026#34;09:20:49.620298462\u0026#34;, \u0026#34;evt.type\u0026#34;: \u0026#34;unlink\u0026#34;, \u0026#34;fd.name\u0026#34;: \u0026#34;\u0026lt;NA\u0026gt;\u0026#34;, \u0026#34;proc.cmdline\u0026#34;: \u0026#34;zsh\u0026#34;, \u0026#34;user.name\u0026#34;: \u0026#34;vagrant\u0026#34; } } ","summary":"","tags":null,"title":"Go Client","url":"https://v0-43--falcosecurity.netlify.app/docs/developer-guide/grpc/client-go/"},{"category":"docs","content":"Hundreds of developers around the world contribute to Falco open source projects. Our Hall of Fame honors the best of the best.\nFalco Contributor of the Month The title of “Contributor of the Month” is awarded to an outstanding contributor for the month of the year.\nMonth of the Year Contributor of the Month November, 2020 Thomas Labarussias December, 2020 Massimiliano Giovagnoli, and Jonah Jones January, 2021 Carlos Panato, KeisukeYamashita, and Rajakavitha Kodhandapani February, 2021 Scott Nichols March, 2021 Frank Jogeleit April, 2021 Batuhan Apaydın and Yuvraj May, 2021 Batuhan Apaydın and Yuvraj June, 2021 Ismail Yenigul July, 2021 Furkan Türkal August, 2021 Teryl Taylor and Frederico Araujo September and October, 2021 Leo Di Donato November and December, 2021 Pablo Lopez Zaldivar January and February, 2022 Alban Créquy January 2023 Logan Bond February 2023 Melissa Kilby and David Windsor ","summary":"","tags":null,"title":"Contributor of the Month","url":"https://v0-43--falcosecurity.netlify.app/docs/contribute/contributor-of-the-month/"},{"category":"docs","content":"Here are the system call event types and args supported by the kernel module and eBPF probes via libscap included in the Falco libs. Note that, for performance reasons, by default Falco will only consider a subset of them indicated in the table below with \u0026quot;yes\u0026quot;. However, it's possible to make Falco consider all events by using the -A command line switch.\nNote that several event types exist:\nSyscall events correspond to Linux system calls. Most of them have parameters, documented below, while some are detected as generic and they only offer the syscall ID. Tracepoint events represent internal kernel events that may be significant but don't directly translate to any syscall. Metaevents are generated from supplementary data sources, for instance, during data enrichment procedures or when the need for asynchronous actions arises. This group also encompasses some of Falco's internally produced events (such as the drop event) that are unavailable for rules. Plugin events act as an envelope for actual plugin event data. In order to write rules that use plugins use the fields documented in the individual plugin. \u0026lt;p\u0026gt;The events below are valid for Falco \u0026lt;em\u0026gt;Schema Version\u0026lt;/em\u0026gt;: 4.1.0\u0026lt;/p\u0026gt; Syscall events Default Dir Name Params Yes \u0026gt; open FSPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode Yes \u0026lt; open FD fd, FSPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode, UINT32 dev, UINT64 ino Yes \u0026lt; close ERRNO res, FD fd No \u0026lt; read ERRNO res, BYTEBUF data, FD fd, UINT32 size No \u0026lt; write ERRNO res, BYTEBUF data, FD fd, UINT32 size Yes \u0026lt; socket FD fd, ENUMFLAGS32 domain: AF_NFC, AF_ALG, AF_CAIF, AF_IEEE802154, AF_PHONET, AF_ISDN, AF_RXRPC, AF_IUCV, AF_BLUETOOTH, AF_TIPC, AF_CAN, AF_LLC, AF_WANPIPE, AF_PPPOX, AF_IRDA, AF_SNA, AF_RDS, AF_ATMSVC, AF_ECONET, AF_ASH, AF_PACKET, AF_ROUTE, AF_NETLINK, AF_KEY, AF_SECURITY, AF_NETBEUI, AF_DECnet, AF_ROSE, AF_INET6, AF_X25, AF_ATMPVC, AF_BRIDGE, AF_NETROM, AF_APPLETALK, AF_IPX, AF_AX25, AF_INET, AF_LOCAL, AF_UNIX, AF_UNSPEC, UINT32 type, UINT32 proto Yes \u0026lt; bind ERRNO res, SOCKADDR addr, FD fd Yes \u0026gt; connect FD fd, SOCKADDR addr Yes \u0026lt; connect ERRNO res, SOCKTUPLE tuple, FD fd, SOCKADDR addr Yes \u0026lt; listen ERRNO res, FD fd, INT32 backlog No \u0026lt; send ERRNO res, BYTEBUF data, FD fd, UINT32 size, SOCKTUPLE tuple Yes \u0026lt; sendto ERRNO res, BYTEBUF data, FD fd, UINT32 size, SOCKTUPLE tuple No \u0026lt; recv ERRNO res, BYTEBUF data, FD fd, UINT32 size, SOCKTUPLE tuple Yes \u0026lt; recvfrom ERRNO res, BYTEBUF data, SOCKTUPLE tuple, FD fd, UINT32 size Yes \u0026lt; shutdown ERRNO res, FD fd, ENUMFLAGS8 how: SHUT_UNKNOWN, SHUT_RDWR, SHUT_WR, SHUT_RD Yes \u0026lt; getsockname Yes \u0026lt; getpeername Yes \u0026lt; socketpair ERRNO res, FD fd1, FD fd2, UINT64 source, UINT64 peer, ENUMFLAGS32 domain: AF_NFC, AF_ALG, AF_CAIF, AF_IEEE802154, AF_PHONET, AF_ISDN, AF_RXRPC, AF_IUCV, AF_BLUETOOTH, AF_TIPC, AF_CAN, AF_LLC, AF_WANPIPE, AF_PPPOX, AF_IRDA, AF_SNA, AF_RDS, AF_ATMSVC, AF_ECONET, AF_ASH, AF_PACKET, AF_ROUTE, AF_NETLINK, AF_KEY, AF_SECURITY, AF_NETBEUI, AF_DECnet, AF_ROSE, AF_INET6, AF_X25, AF_ATMPVC, AF_BRIDGE, AF_NETROM, AF_APPLETALK, AF_IPX, AF_AX25, AF_INET, AF_LOCAL, AF_UNIX, AF_UNSPEC, UINT32 type, UINT32 proto Yes \u0026lt; setsockopt ERRNO res, FD fd, ENUMFLAGS8 level: SOL_SOCKET, SOL_TCP, UNKNOWN, ENUMFLAGS8 optname: SO_COOKIE, SO_MEMINFO, SO_PEERGROUPS, SO_ATTACH_BPF, SO_INCOMING_CPU, SO_BPF_EXTENSIONS, SO_MAX_PACING_RATE, SO_BUSY_POLL, SO_SELECT_ERR_QUEUE, SO_LOCK_FILTER, SO_NOFCS, SO_PEEK_OFF, SO_WIFI_STATUS, SO_RXQ_OVFL, SO_DOMAIN, SO_PROTOCOL, SO_TIMESTAMPING, SO_MARK, SO_TIMESTAMPNS, SO_PASSSEC, SO_PEERSEC, SO_ACCEPTCONN, SO_TIMESTAMP, SO_PEERNAME, SO_DETACH_FILTER, SO_ATTACH_FILTER, SO_BINDTODEVICE, SO_SECURITY_ENCRYPTION_NETWORK, SO_SECURITY_ENCRYPTION_TRANSPORT, SO_SECURITY_AUTHENTICATION, SO_SNDTIMEO, SO_RCVTIMEO, SO_SNDLOWAT, SO_RCVLOWAT, SO_PEERCRED, SO_PASSCRED, SO_REUSEPORT, SO_BSDCOMPAT, SO_LINGER, SO_PRIORITY, SO_NO_CHECK, SO_OOBINLINE, SO_KEEPALIVE, SO_RCVBUFFORCE, SO_SNDBUFFORCE, SO_RCVBUF, SO_SNDBUF, SO_BROADCAST, SO_DONTROUTE, SO_ERROR, SO_TYPE, SO_REUSEADDR, SO_DEBUG, UNKNOWN, DYNAMIC val, UINT32 optlen Yes \u0026lt; getsockopt ERRNO res, FD fd, ENUMFLAGS8 level: SOL_SOCKET, SOL_TCP, UNKNOWN, ENUMFLAGS8 optname: SO_COOKIE, SO_MEMINFO, SO_PEERGROUPS, SO_ATTACH_BPF, SO_INCOMING_CPU, SO_BPF_EXTENSIONS, SO_MAX_PACING_RATE, SO_BUSY_POLL, SO_SELECT_ERR_QUEUE, SO_LOCK_FILTER, SO_NOFCS, SO_PEEK_OFF, SO_WIFI_STATUS, SO_RXQ_OVFL, SO_DOMAIN, SO_PROTOCOL, SO_TIMESTAMPING, SO_MARK, SO_TIMESTAMPNS, SO_PASSSEC, SO_PEERSEC, SO_ACCEPTCONN, SO_TIMESTAMP, SO_PEERNAME, SO_DETACH_FILTER, SO_ATTACH_FILTER, SO_BINDTODEVICE, SO_SECURITY_ENCRYPTION_NETWORK, SO_SECURITY_ENCRYPTION_TRANSPORT, SO_SECURITY_AUTHENTICATION, SO_SNDTIMEO, SO_RCVTIMEO, SO_SNDLOWAT, SO_RCVLOWAT, SO_PEERCRED, SO_PASSCRED, SO_REUSEPORT, SO_BSDCOMPAT, SO_LINGER, SO_PRIORITY, SO_NO_CHECK, SO_OOBINLINE, SO_KEEPALIVE, SO_RCVBUFFORCE, SO_SNDBUFFORCE, SO_RCVBUF, SO_SNDBUF, SO_BROADCAST, SO_DONTROUTE, SO_ERROR, SO_TYPE, SO_REUSEADDR, SO_DEBUG, UNKNOWN, DYNAMIC val, UINT32 optlen Yes \u0026lt; sendmsg ERRNO res, BYTEBUF data, FD fd, UINT32 size, SOCKTUPLE tuple Yes \u0026lt; sendmmsg ERRNO res, FD fd, UINT32 size, BYTEBUF data, SOCKTUPLE tuple Yes \u0026lt; recvmsg ERRNO res, UINT32 size, BYTEBUF data, SOCKTUPLE tuple, BYTEBUF msgcontrol, FD fd Yes \u0026lt; recvmmsg ERRNO res, FD fd, UINT32 size, BYTEBUF data, SOCKTUPLE tuple, BYTEBUF msgcontrol Yes \u0026gt; creat FSPATH name, UINT32 mode Yes \u0026lt; creat FD fd, FSPATH name, UINT32 mode, UINT32 dev, UINT64 ino, FLAGS16 creat_flags: FD_UPPER_LAYER_CREAT, FD_LOWER_LAYER_CREAT Yes \u0026lt; pipe ERRNO res, FD fd1, FD fd2, UINT64 ino Yes \u0026lt; eventfd FD res, UINT64 initval, UINT32 flags Yes \u0026lt; futex ERRNO res, UINT64 addr, FLAGS16 op: FUTEX_CLOCK_REALTIME, FUTEX_PRIVATE_FLAG, FUTEX_CMP_REQUEUE_PI, FUTEX_WAIT_REQUEUE_PI, FUTEX_WAKE_BITSET, FUTEX_WAIT_BITSET, FUTEX_TRYLOCK_PI, FUTEX_UNLOCK_PI, FUTEX_LOCK_PI, FUTEX_WAKE_OP, FUTEX_CMP_REQUEUE, FUTEX_REQUEUE, FUTEX_FD, FUTEX_WAKE, FUTEX_WAIT, UINT64 val Yes \u0026lt; stat ERRNO res, FSPATH path Yes \u0026lt; lstat ERRNO res, FSPATH path Yes \u0026lt; fstat ERRNO res, FD fd Yes \u0026lt; stat64 ERRNO res, FSPATH path Yes \u0026lt; lstat64 ERRNO res, FSPATH path Yes \u0026lt; fstat64 ERRNO res Yes \u0026lt; epoll_wait ERRNO res, ERRNO maxevents Yes \u0026lt; poll ERRNO res, FDLIST fds, INT64 timeout Yes \u0026lt; select ERRNO res Yes \u0026lt; lseek ERRNO res, FD fd, UINT64 offset, ENUMFLAGS8 whence: SEEK_END, SEEK_CUR, SEEK_SET Yes \u0026lt; llseek ERRNO res, FD fd, UINT64 offset, ENUMFLAGS8 whence: SEEK_END, SEEK_CUR, SEEK_SET Yes \u0026lt; getcwd ERRNO res, CHARBUF path Yes \u0026lt; chdir ERRNO res, CHARBUF path Yes \u0026lt; fchdir ERRNO res, FD fd No \u0026lt; pread ERRNO res, BYTEBUF data, FD fd, UINT32 size, UINT64 pos No \u0026lt; pwrite ERRNO res, BYTEBUF data, FD fd, UINT32 size, UINT64 pos No \u0026lt; readv ERRNO res, UINT32 size, BYTEBUF data, FD fd No \u0026lt; writev ERRNO res, BYTEBUF data, FD fd, UINT32 size No \u0026lt; preadv ERRNO res, UINT32 size, BYTEBUF data, FD fd, UINT64 pos No \u0026lt; pwritev ERRNO res, BYTEBUF data, FD fd, UINT32 size, UINT64 pos Yes \u0026lt; signalfd FD res, FD fd, UINT32 mask, UINT8 flags Yes \u0026lt; kill ERRNO res, PID pid, SIGTYPE sig Yes \u0026lt; tkill ERRNO res, PID tid, SIGTYPE sig Yes \u0026lt; tgkill ERRNO res, PID pid, PID tid, SIGTYPE sig Yes \u0026lt; nanosleep ERRNO res, RELTIME interval Yes \u0026lt; timerfd_create FD res, UINT8 clockid, UINT8 flags Yes \u0026lt; inotify_init FD res, UINT8 flags Yes \u0026lt; getrlimit ERRNO res, INT64 cur, INT64 max, ENUMFLAGS8 resource: RLIMIT_UNKNOWN, RLIMIT_RTTIME, RLIMIT_RTPRIO, RLIMIT_NICE, RLIMIT_MSGQUEUE, RLIMIT_SIGPENDING, RLIMIT_LOCKS, RLIMIT_AS, RLIMIT_MEMLOCK, RLIMIT_NOFILE, RLIMIT_NPROC, RLIMIT_RSS, RLIMIT_CORE, RLIMIT_STACK, RLIMIT_DATA, RLIMIT_FSIZE, RLIMIT_CPU Yes \u0026lt; setrlimit ERRNO res, INT64 cur, INT64 max, ENUMFLAGS8 resource: RLIMIT_UNKNOWN, RLIMIT_RTTIME, RLIMIT_RTPRIO, RLIMIT_NICE, RLIMIT_MSGQUEUE, RLIMIT_SIGPENDING, RLIMIT_LOCKS, RLIMIT_AS, RLIMIT_MEMLOCK, RLIMIT_NOFILE, RLIMIT_NPROC, RLIMIT_RSS, RLIMIT_CORE, RLIMIT_STACK, RLIMIT_DATA, RLIMIT_FSIZE, RLIMIT_CPU Yes \u0026lt; prlimit ERRNO res, INT64 newcur, INT64 newmax, INT64 oldcur, INT64 oldmax, INT64 pid, ENUMFLAGS8 resource: RLIMIT_UNKNOWN, RLIMIT_RTTIME, RLIMIT_RTPRIO, RLIMIT_NICE, RLIMIT_MSGQUEUE, RLIMIT_SIGPENDING, RLIMIT_LOCKS, RLIMIT_AS, RLIMIT_MEMLOCK, RLIMIT_NOFILE, RLIMIT_NPROC, RLIMIT_RSS, RLIMIT_CORE, RLIMIT_STACK, RLIMIT_DATA, RLIMIT_FSIZE, RLIMIT_CPU Yes \u0026lt; fcntl FD res, FD fd, ENUMFLAGS8 cmd: F_GETPIPE_SZ, F_SETPIPE_SZ, F_NOTIFY, F_DUPFD_CLOEXEC, F_CANCELLK, F_GETLEASE, F_SETLEASE, F_GETOWN_EX, F_SETOWN_EX, F_SETLKW64, F_SETLK64, F_GETLK64, F_GETSIG, F_SETSIG, F_GETOWN, F_SETOWN, F_SETLKW, F_SETLK, F_GETLK, F_SETFL, F_GETFL, F_SETFD, F_GETFD, F_DUPFD, F_OFD_GETLK, F_OFD_SETLK, F_OFD_SETLKW, UNKNOWN Yes \u0026lt; brk UINT64 res, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, UINT64 addr Yes \u0026lt; mmap ERRNO res, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, UINT64 addr, UINT64 length, FLAGS32 prot: PROT_READ, PROT_WRITE, PROT_EXEC, PROT_SEM, PROT_GROWSDOWN, PROT_GROWSUP, PROT_SAO, PROT_NONE, FLAGS32 flags: MAP_SHARED, MAP_PRIVATE, MAP_FIXED, MAP_ANONYMOUS, MAP_32BIT, MAP_RENAME, MAP_NORESERVE, MAP_POPULATE, MAP_NONBLOCK, MAP_GROWSDOWN, MAP_DENYWRITE, MAP_EXECUTABLE, MAP_INHERIT, MAP_FILE, MAP_LOCKED, FD fd, UINT64 offset Yes \u0026lt; mmap2 ERRNO res, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, UINT64 addr, UINT64 length, FLAGS32 prot: PROT_READ, PROT_WRITE, PROT_EXEC, PROT_SEM, PROT_GROWSDOWN, PROT_GROWSUP, PROT_SAO, PROT_NONE, FLAGS32 flags: MAP_SHARED, MAP_PRIVATE, MAP_FIXED, MAP_ANONYMOUS, MAP_32BIT, MAP_RENAME, MAP_NORESERVE, MAP_POPULATE, MAP_NONBLOCK, MAP_GROWSDOWN, MAP_DENYWRITE, MAP_EXECUTABLE, MAP_INHERIT, MAP_FILE, MAP_LOCKED, FD fd, UINT64 pgoffset Yes \u0026lt; munmap ERRNO res, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, UINT64 addr, UINT64 length Yes \u0026lt; splice ERRNO res, FD fd_in, FD fd_out, UINT64 size, FLAGS32 flags: SPLICE_F_MOVE, SPLICE_F_NONBLOCK, SPLICE_F_MORE, SPLICE_F_GIFT Yes \u0026lt; ptrace ERRNO res, DYNAMIC addr, DYNAMIC data, ENUMFLAGS16 request: PTRACE_SINGLEBLOCK, PTRACE_SYSEMU_SINGLESTEP, PTRACE_SYSEMU, PTRACE_ARCH_PRCTL, PTRACE_SET_THREAD_AREA, PTRACE_GET_THREAD_AREA, PTRACE_OLDSETOPTIONS, PTRACE_SETFPXREGS, PTRACE_GETFPXREGS, PTRACE_SETFPREGS, PTRACE_GETFPREGS, PTRACE_SETREGS, PTRACE_GETREGS, PTRACE_SETSIGMASK, PTRACE_GETSIGMASK, PTRACE_PEEKSIGINFO, PTRACE_LISTEN, PTRACE_INTERRUPT, PTRACE_SEIZE, PTRACE_SETREGSET, PTRACE_GETREGSET, PTRACE_SETSIGINFO, PTRACE_GETSIGINFO, PTRACE_GETEVENTMSG, PTRACE_SETOPTIONS, PTRACE_SYSCALL, PTRACE_DETACH, PTRACE_ATTACH, PTRACE_SINGLESTEP, PTRACE_KILL, PTRACE_CONT, PTRACE_POKEUSR, PTRACE_POKEDATA, PTRACE_POKETEXT, PTRACE_PEEKUSR, PTRACE_PEEKDATA, PTRACE_PEEKTEXT, PTRACE_TRACEME, PTRACE_UNKNOWN, PID pid Yes \u0026lt; ioctl ERRNO res, FD fd, UINT64 request, UINT64 argument Yes \u0026lt; rename ERRNO res, FSPATH oldpath, FSPATH newpath Yes \u0026lt; renameat ERRNO res, FD olddirfd, FSRELPATH oldpath, FD newdirfd, FSRELPATH newpath Yes \u0026lt; symlink ERRNO res, CHARBUF target, FSPATH linkpath Yes \u0026lt; symlinkat ERRNO res, CHARBUF target, FD linkdirfd, FSRELPATH linkpath No \u0026lt; sendfile ERRNO res, UINT64 offset, FD out_fd, FD in_fd, UINT64 size Yes \u0026lt; quotactl ERRNO res, CHARBUF special, CHARBUF quotafilepath, UINT64 dqb_bhardlimit, UINT64 dqb_bsoftlimit, UINT64 dqb_curspace, UINT64 dqb_ihardlimit, UINT64 dqb_isoftlimit, RELTIME dqb_btime, RELTIME dqb_itime, RELTIME dqi_bgrace, RELTIME dqi_igrace, FLAGS8 dqi_flags: DQF_NONE, V1_DQF_RSQUASH, FLAGS8 quota_fmt_out: QFMT_NOT_USED, QFMT_VFS_OLD, QFMT_VFS_V0, QFMT_VFS_V1, FLAGS16 cmd: Q_QUOTAON, Q_QUOTAOFF, Q_GETFMT, Q_GETINFO, Q_SETINFO, Q_GETQUOTA, Q_SETQUOTA, Q_SYNC, Q_XQUOTAON, Q_XQUOTAOFF, Q_XGETQUOTA, Q_XSETQLIM, Q_XGETQSTAT, Q_XQUOTARM, Q_XQUOTASYNC, FLAGS8 type: USRQUOTA, GRPQUOTA, UINT32 id, FLAGS8 quota_fmt: QFMT_NOT_USED, QFMT_VFS_OLD, QFMT_VFS_V0, QFMT_VFS_V1 Yes \u0026lt; setresuid ERRNO res, UID ruid, UID euid, UID suid Yes \u0026lt; setresgid ERRNO res, GID rgid, GID egid, GID sgid Yes \u0026lt; setuid ERRNO res, UID uid Yes \u0026lt; setgid ERRNO res, GID gid Yes \u0026lt; getuid UID uid Yes \u0026lt; geteuid UID euid Yes \u0026lt; getgid GID gid Yes \u0026lt; getegid GID egid Yes \u0026lt; getresuid ERRNO res, UID ruid, UID euid, UID suid Yes \u0026lt; getresgid ERRNO res, GID rgid, GID egid, GID sgid Yes \u0026lt; clone PID res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, INT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, FLAGS32 flags: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP, CLONE_CHILD_IN_PIDNS, UINT32 uid, UINT32 gid, PID vtid, PID vpid, UINT64 pidns_init_start_ts Yes \u0026lt; fork PID res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, INT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, FLAGS32 flags: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP, CLONE_CHILD_IN_PIDNS, UINT32 uid, UINT32 gid, PID vtid, PID vpid, UINT64 pidns_init_start_ts Yes \u0026lt; vfork PID res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, INT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, FLAGS32 flags: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP, CLONE_CHILD_IN_PIDNS, UINT32 uid, UINT32 gid, PID vtid, PID vpid, UINT64 pidns_init_start_ts Yes \u0026lt; getdents ERRNO res, FD fd Yes \u0026lt; getdents64 ERRNO res, FD fd Yes \u0026lt; setns ERRNO res, FD fd, FLAGS32 nstype: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP, CLONE_CHILD_IN_PIDNS Yes \u0026lt; flock ERRNO res, FD fd, FLAGS32 operation: LOCK_SH, LOCK_EX, LOCK_NB, LOCK_UN, LOCK_NONE Yes \u0026lt; accept FD fd, SOCKTUPLE tuple, UINT8 queuepct, UINT32 queuelen, UINT32 queuemax Yes \u0026lt; semop ERRNO res, UINT32 nsops, UINT16 sem_num_0, INT16 sem_op_0, FLAGS16 sem_flg_0: IPC_NOWAIT, SEM_UNDO, UINT16 sem_num_1, INT16 sem_op_1, FLAGS16 sem_flg_1: IPC_NOWAIT, SEM_UNDO, INT32 semid Yes \u0026lt; semctl ERRNO res, INT32 semid, INT32 semnum, FLAGS16 cmd: IPC_STAT, IPC_SET, IPC_RMID, IPC_INFO, SEM_INFO, SEM_STAT, GETALL, GETNCNT, GETPID, GETVAL, GETZCNT, SETALL, SETVAL, INT32 val Yes \u0026lt; ppoll ERRNO res, FDLIST fds, RELTIME timeout, SIGSET sigmask Yes \u0026lt; mount ERRNO res, CHARBUF dev, FSPATH dir, CHARBUF type, FLAGS32 flags: RDONLY, NOSUID, NODEV, NOEXEC, SYNCHRONOUS, REMOUNT, MANDLOCK, DIRSYNC, NOATIME, NODIRATIME, BIND, MOVE, REC, SILENT, POSIXACL, UNBINDABLE, PRIVATE, SLAVE, SHARED, RELATIME, KERNMOUNT, I_VERSION, STRICTATIME, LAZYTIME, NOSEC, BORN, ACTIVE, NOUSER Yes \u0026lt; semget ERRNO res, INT32 key, INT32 nsems, FLAGS32 semflg: IPC_EXCL, IPC_CREAT Yes \u0026lt; access ERRNO res, FSPATH name, FLAGS32 mode: F_OK, R_OK, W_OK, X_OK Yes \u0026lt; chroot ERRNO res, FSPATH path Yes \u0026lt; setsid PID res Yes \u0026lt; mkdir ERRNO res, FSPATH path, UINT32 mode Yes \u0026lt; rmdir ERRNO res, FSPATH path Yes \u0026lt; unshare ERRNO res, FLAGS32 flags: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP, CLONE_CHILD_IN_PIDNS Yes \u0026lt; execve ERRNO res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, UINT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, BYTEBUF env, UINT32 tty, PID vpgid, UID loginuid, FLAGS32 flags: EXE_WRITABLE, EXE_UPPER_LAYER, EXE_FROM_MEMFD, EXE_LOWER_LAYER, UINT64 cap_inheritable, UINT64 cap_permitted, UINT64 cap_effective, UINT64 exe_ino, ABSTIME exe_ino_ctime, ABSTIME exe_ino_mtime, UID uid, FSPATH trusted_exepath, PID pgid, GID gid, FSPATH filename Yes \u0026lt; setpgid ERRNO res, PID pid, PID pgid Yes \u0026lt; seccomp ERRNO res, UINT64 op, UINT64 flags Yes \u0026lt; unlink ERRNO res, FSPATH path Yes \u0026lt; unlinkat ERRNO res, FD dirfd, FSRELPATH name, FLAGS32 flags: AT_REMOVEDIR Yes \u0026lt; mkdirat ERRNO res, FD dirfd, FSRELPATH path, UINT32 mode Yes \u0026gt; openat FD dirfd, FSRELPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode Yes \u0026lt; openat FD fd, FD dirfd, FSRELPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode, UINT32 dev, UINT64 ino Yes \u0026lt; link ERRNO res, FSPATH oldpath, FSPATH newpath Yes \u0026lt; linkat ERRNO res, FD olddir, FSRELPATH oldpath, FD newdir, FSRELPATH newpath, FLAGS32 flags: AT_SYMLINK_FOLLOW, AT_EMPTY_PATH Yes \u0026lt; fchmodat ERRNO res, FD dirfd, FSRELPATH filename, MODE mode Yes \u0026lt; chmod ERRNO res, FSPATH filename, MODE mode Yes \u0026lt; fchmod ERRNO res, FD fd, MODE mode Yes \u0026lt; renameat2 ERRNO res, FD olddirfd, FSRELPATH oldpath, FD newdirfd, FSRELPATH newpath, FLAGS32 flags: RENAME_NOREPLACE, RENAME_EXCHANGE, RENAME_WHITEOUT Yes \u0026lt; userfaultfd ERRNO res, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER Yes \u0026gt; openat2 FD dirfd, FSRELPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode, FLAGS32 resolve: RESOLVE_BENEATH, RESOLVE_IN_ROOT, RESOLVE_NO_MAGICLINKS, RESOLVE_NO_SYMLINKS, RESOLVE_NO_XDEV, RESOLVE_CACHED Yes \u0026lt; openat2 FD fd, FD dirfd, FSRELPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode, FLAGS32 resolve: RESOLVE_BENEATH, RESOLVE_IN_ROOT, RESOLVE_NO_MAGICLINKS, RESOLVE_NO_SYMLINKS, RESOLVE_NO_XDEV, RESOLVE_CACHED, UINT32 dev, UINT64 ino Yes \u0026lt; mprotect ERRNO res, UINT64 addr, UINT64 length, FLAGS32 prot: PROT_READ, PROT_WRITE, PROT_EXEC, PROT_SEM, PROT_GROWSDOWN, PROT_GROWSUP, PROT_SAO, PROT_NONE Yes \u0026lt; execveat ERRNO res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, UINT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, BYTEBUF env, UINT32 tty, PID vpgid, UID loginuid, FLAGS32 flags: EXE_WRITABLE, EXE_UPPER_LAYER, EXE_FROM_MEMFD, EXE_LOWER_LAYER, UINT64 cap_inheritable, UINT64 cap_permitted, UINT64 cap_effective, UINT64 exe_ino, ABSTIME exe_ino_ctime, ABSTIME exe_ino_mtime, UID uid, FSPATH trusted_exepath, PID pgid, GID gid Yes \u0026lt; copy_file_range ERRNO res, FD fdout, UINT64 offout, FD fdin, UINT64 offin, UINT64 len Yes \u0026lt; clone3 PID res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, INT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, FLAGS32 flags: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP, CLONE_CHILD_IN_PIDNS, UINT32 uid, UINT32 gid, PID vtid, PID vpid, UINT64 pidns_init_start_ts Yes \u0026lt; open_by_handle_at FD fd, FD mountfd, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, FSPATH path, UINT32 dev, UINT64 ino Yes \u0026lt; io_uring_setup ERRNO res, UINT32 entries, UINT32 sq_entries, UINT32 cq_entries, FLAGS32 flags: IORING_SETUP_IOPOLL, IORING_SETUP_SQPOLL, IORING_SQ_NEED_WAKEUP, IORING_SETUP_SQ_AFF, IORING_SETUP_CQSIZE, IORING_SETUP_CLAMP, IORING_SETUP_ATTACH_RW, IORING_SETUP_R_DISABLED, UINT32 sq_thread_cpu, UINT32 sq_thread_idle, FLAGS32 features: IORING_FEAT_SINGLE_MMAP, IORING_FEAT_NODROP, IORING_FEAT_SUBMIT_STABLE, IORING_FEAT_RW_CUR_POS, IORING_FEAT_CUR_PERSONALITY, IORING_FEAT_FAST_POLL, IORING_FEAT_POLL_32BITS, IORING_FEAT_SQPOLL_NONFIXED, IORING_FEAT_ENTER_EXT_ARG, IORING_FEAT_NATIVE_WORKERS, IORING_FEAT_RSRC_TAGS Yes \u0026lt; io_uring_enter ERRNO res, FD fd, UINT32 to_submit, UINT32 min_complete, FLAGS32 flags: IORING_ENTER_GETEVENTS, IORING_ENTER_SQ_WAKEUP, IORING_ENTER_SQ_WAIT, IORING_ENTER_EXT_ARG, SIGSET sig Yes \u0026lt; io_uring_register ERRNO res, FD fd, ENUMFLAGS16 opcode: IORING_REGISTER_BUFFERS, IORING_UNREGISTER_BUFFERS, IORING_REGISTER_FILES, IORING_UNREGISTER_FILES, IORING_REGISTER_EVENTFD, IORING_UNREGISTER_EVENTFD, IORING_REGISTER_FILES_UPDATE, IORING_REGISTER_EVENTFD_ASYNC, IORING_REGISTER_PROBE, IORING_REGISTER_PERSONALITY, IORING_UNREGISTER_PERSONALITY, IORING_REGISTER_RESTRICTIONS, IORING_REGISTER_ENABLE_RINGS, IORING_REGISTER_FILES2, IORING_REGISTER_FILES_UPDATE2, IORING_REGISTER_BUFFERS2, IORING_REGISTER_BUFFERS_UPDATE, IORING_REGISTER_IOWQ_AFF, IORING_UNREGISTER_IOWQ_AFF, IORING_REGISTER_IOWQ_MAX_WORKERS, IORING_REGISTER_RING_FDS, IORING_UNREGISTER_RING_FDS, UINT64 arg, UINT32 nr_args Yes \u0026lt; mlock ERRNO res, UINT64 addr, UINT64 len Yes \u0026lt; munlock ERRNO res, UINT64 addr, UINT64 len Yes \u0026lt; mlockall ERRNO res, FLAGS32 flags: MCL_CURRENT, MCL_FUTURE, MCL_ONFAULT Yes \u0026lt; munlockall ERRNO res Yes \u0026lt; capset ERRNO res, UINT64 cap_inheritable, UINT64 cap_permitted, UINT64 cap_effective Yes \u0026lt; dup2 FD res, FD oldfd, FD newfd Yes \u0026lt; dup3 FD res, FD oldfd, FD newfd, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER Yes \u0026lt; dup FD res, FD oldfd Yes \u0026lt; bpf FD fd, ENUMFLAGS32 cmd: BPF_MAP_CREATE, BPF_MAP_LOOKUP_ELEM, BPF_MAP_UPDATE_ELEM, BPF_MAP_DELETE_ELEM, BPF_MAP_GET_NEXT_KEY, BPF_PROG_LOAD, BPF_OBJ_PIN, BPF_OBJ_GET, BPF_PROG_ATTACH, BPF_PROG_DETACH, BPF_PROG_TEST_RUN, BPF_PROG_RUN, BPF_PROG_GET_NEXT_ID, BPF_MAP_GET_NEXT_ID, BPF_PROG_GET_FD_BY_ID, BPF_MAP_GET_FD_BY_ID, BPF_OBJ_GET_INFO_BY_FD, BPF_PROG_QUERY, BPF_RAW_TRACEPOINT_OPEN, BPF_BTF_LOAD, BPF_BTF_GET_FD_BY_ID, BPF_TASK_FD_QUERY, BPF_MAP_LOOKUP_AND_DELETE_ELEM, BPF_MAP_FREEZE, BPF_BTF_GET_NEXT_ID, BPF_MAP_LOOKUP_BATCH, BPF_MAP_LOOKUP_AND_DELETE_BATCH, BPF_MAP_UPDATE_BATCH, BPF_MAP_DELETE_BATCH, BPF_LINK_CREATE, BPF_LINK_UPDATE, BPF_LINK_GET_FD_BY_ID, BPF_LINK_GET_NEXT_ID, BPF_ENABLE_STATS, BPF_ITER_CREATE, BPF_LINK_DETACH, BPF_PROG_BIND_MAP Yes \u0026lt; mlock2 ERRNO res, UINT64 addr, UINT64 len, FLAGS32 flags: MLOCK_ONFAULT Yes \u0026lt; fsconfig ERRNO res, FD fd, ENUMFLAGS32 cmd: FSCONFIG_SET_FLAG, FSCONFIG_SET_STRING, FSCONFIG_SET_BINARY, FSCONFIG_SET_PATH, FSCONFIG_SET_PATH_EMPTY, FSCONFIG_SET_FD, FSCONFIG_CMD_CREATE, FSCONFIG_CMD_RECONFIGURE, CHARBUF key, BYTEBUF value_bytebuf, CHARBUF value_charbuf, INT32 aux Yes \u0026lt; epoll_create ERRNO res, INT32 size Yes \u0026lt; epoll_create1 ERRNO res, FLAGS32 flags: EPOLL_CLOEXEC Yes \u0026lt; chown ERRNO res, FSPATH path, UINT32 uid, UINT32 gid Yes \u0026lt; lchown ERRNO res, FSPATH path, UINT32 uid, UINT32 gid Yes \u0026lt; fchown ERRNO res, FD fd, UINT32 uid, UINT32 gid Yes \u0026lt; fchownat ERRNO res, FD dirfd, FSRELPATH pathname, UINT32 uid, UINT32 gid, FLAGS32 flags: AT_SYMLINK_NOFOLLOW, AT_EMPTY_PATH Yes \u0026lt; umount ERRNO res, FSPATH name Yes \u0026lt; accept4 FD fd, SOCKTUPLE tuple, UINT8 queuepct, UINT32 queuelen, UINT32 queuemax, INT32 flags Yes \u0026lt; umount2 ERRNO res, FSPATH name, FLAGS32 flags: FORCE, DETACH, EXPIRE, NOFOLLOW Yes \u0026lt; pipe2 ERRNO res, FD fd1, FD fd2, UINT64 ino, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER Yes \u0026lt; inotify_init1 FD res, FLAGS16 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER Yes \u0026lt; eventfd2 FD res, FLAGS16 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT64 initval Yes \u0026lt; signalfd4 FD res, FLAGS16 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, FD fd, UINT32 mask Yes \u0026lt; prctl ERRNO res, ENUMFLAGS32 option: PR_GET_DUMPABLE, PR_SET_DUMPABLE, PR_GET_KEEPCAPS, PR_SET_KEEPCAPS, PR_SET_NAME, PR_GET_NAME, PR_GET_SECCOMP, PR_SET_SECCOMP, PR_CAPBSET_READ, PR_CAPBSET_DROP, PR_GET_SECUREBITS, PR_SET_SECUREBITS, PR_MCE_KILL, PR_MCE_KILL, PR_SET_MM, PR_SET_CHILD_SUBREAPER, PR_GET_CHILD_SUBREAPER, PR_SET_NO_NEW_PRIVS, PR_GET_NO_NEW_PRIVS, PR_GET_TID_ADDRESS, PR_SET_THP_DISABLE, PR_GET_THP_DISABLE, PR_CAP_AMBIENT, CHARBUF arg2_str, INT64 arg2_int Yes \u0026lt; memfd_create FD fd, CHARBUF name, FLAGS32 flags: MFD_CLOEXEC, MFD_ALLOW_SEALING, MFD_HUGETLB Yes \u0026lt; pidfd_getfd FD fd, FD pid_fd, FD target_fd, UINT32 flags Yes \u0026lt; pidfd_open FD fd, PID pid, FLAGS32 flags: PIDFD_NONBLOCK Yes \u0026lt; init_module ERRNO res, BYTEBUF img, UINT64 length, CHARBUF uargs Yes \u0026lt; finit_module ERRNO res, FD fd, CHARBUF uargs, FLAGS32 flags: MODULE_INIT_IGNORE_MODVERSIONS, MODULE_INIT_IGNORE_VERMAGIC, MODULE_INIT_COMPRESSED_FILE Yes \u0026lt; mknod ERRNO res, FSPATH path, MODE mode, UINT32 dev Yes \u0026lt; mknodat ERRNO res, FD dirfd, FSRELPATH path, MODE mode, UINT32 dev Yes \u0026lt; newfstatat ERRNO res, FD dirfd, FSRELPATH path, FLAGS32 flags: AT_EMPTY_PATH, AT_NO_AUTOMOUNT, AT_SYMLINK_NOFOLLOW Yes \u0026lt; process_vm_readv INT64 res, PID pid, BYTEBUF data Yes \u0026lt; process_vm_writev INT64 res, PID pid, BYTEBUF data Yes \u0026lt; delete_module ERRNO res, CHARBUF name, FLAGS32 flags: O_NONBLOCK, O_TRUNC Yes \u0026lt; setreuid ERRNO res, UID ruid, UID euid Yes \u0026lt; setregid ERRNO res, UID rgid, UID egid Yes \u0026gt; adjtimex SYSCALLID ID, UINT16 nativeID Yes \u0026lt; adjtimex SYSCALLID ID, UINT16 nativeID Yes \u0026gt; exit SYSCALLID ID, UINT16 nativeID Yes \u0026lt; exit SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sethostname SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sethostname SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getsid SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getsid SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fstatfs SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fstatfs SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pivot_root SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pivot_root SYSCALLID ID, UINT16 nativeID Yes \u0026gt; oldstat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; oldstat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; umask SYSCALLID ID, UINT16 nativeID Yes \u0026lt; umask SYSCALLID ID, UINT16 nativeID Yes \u0026gt; madvise SYSCALLID ID, UINT16 nativeID Yes \u0026lt; madvise SYSCALLID ID, UINT16 nativeID Yes \u0026gt; statfs64 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; statfs64 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; iopl SYSCALLID ID, UINT16 nativeID Yes \u0026lt; iopl SYSCALLID ID, UINT16 nativeID Yes \u0026gt; swapon SYSCALLID ID, UINT16 nativeID Yes \u0026lt; swapon SYSCALLID ID, UINT16 nativeID Yes \u0026gt; utime SYSCALLID ID, UINT16 nativeID Yes \u0026lt; utime SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getpid SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getpid SYSCALLID ID, UINT16 nativeID Yes \u0026gt; setdomainname SYSCALLID ID, UINT16 nativeID Yes \u0026lt; setdomainname SYSCALLID ID, UINT16 nativeID Yes \u0026gt; semtimedop SYSCALLID ID, UINT16 nativeID Yes \u0026lt; semtimedop SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mq_notify SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mq_notify SYSCALLID ID, UINT16 nativeID Yes \u0026gt; nfsservctl SYSCALLID ID, UINT16 nativeID Yes \u0026lt; nfsservctl SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pkey_mprotect SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pkey_mprotect SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fgetxattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fgetxattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sysinfo SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sysinfo SYSCALLID ID, UINT16 nativeID Yes \u0026gt; uselib SYSCALLID ID, UINT16 nativeID Yes \u0026lt; uselib SYSCALLID ID, UINT16 nativeID Yes \u0026gt; olduname SYSCALLID ID, UINT16 nativeID Yes \u0026lt; olduname SYSCALLID ID, UINT16 nativeID Yes \u0026gt; set_mempolicy SYSCALLID ID, UINT16 nativeID Yes \u0026lt; set_mempolicy SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getppid SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getppid SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_yield SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_yield SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getrusage SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getrusage SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sigsuspend SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sigsuspend SYSCALLID ID, UINT16 nativeID Yes \u0026gt; riscv_hwprobe SYSCALLID ID, UINT16 nativeID Yes \u0026lt; riscv_hwprobe SYSCALLID ID, UINT16 nativeID Yes \u0026gt; bdflush SYSCALLID ID, UINT16 nativeID Yes \u0026lt; bdflush SYSCALLID ID, UINT16 nativeID Yes \u0026gt; get_kernel_syms SYSCALLID ID, UINT16 nativeID Yes \u0026lt; get_kernel_syms SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pause SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pause SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getpmsg SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getpmsg SYSCALLID ID, UINT16 nativeID Yes \u0026gt; clock_gettime SYSCALLID ID, UINT16 nativeID Yes \u0026lt; clock_gettime SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mq_getsetattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mq_getsetattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; spu_run SYSCALLID ID, UINT16 nativeID Yes \u0026lt; spu_run SYSCALLID ID, UINT16 nativeID Yes \u0026gt; personality SYSCALLID ID, UINT16 nativeID Yes \u0026lt; personality SYSCALLID ID, UINT16 nativeID Yes \u0026gt; request_key SYSCALLID ID, UINT16 nativeID Yes \u0026lt; request_key SYSCALLID ID, UINT16 nativeID Yes \u0026gt; readlink SYSCALLID ID, UINT16 nativeID Yes \u0026lt; readlink SYSCALLID ID, UINT16 nativeID Yes \u0026gt; times SYSCALLID ID, UINT16 nativeID Yes \u0026lt; times SYSCALLID ID, UINT16 nativeID Yes \u0026gt; reboot SYSCALLID ID, UINT16 nativeID Yes \u0026lt; reboot SYSCALLID ID, UINT16 nativeID Yes \u0026gt; syslog SYSCALLID ID, UINT16 nativeID Yes \u0026lt; syslog SYSCALLID ID, UINT16 nativeID Yes \u0026gt; ipc SYSCALLID ID, UINT16 nativeID Yes \u0026lt; ipc SYSCALLID ID, UINT16 nativeID Yes \u0026gt; create_module SYSCALLID ID, UINT16 nativeID Yes \u0026lt; create_module SYSCALLID ID, UINT16 nativeID Yes \u0026gt; listxattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; listxattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; setxattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; setxattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; setpriority SYSCALLID ID, UINT16 nativeID Yes \u0026lt; setpriority SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sigreturn SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sigreturn SYSCALLID ID, UINT16 nativeID Yes \u0026gt; setgroups SYSCALLID ID, UINT16 nativeID Yes \u0026lt; setgroups SYSCALLID ID, UINT16 nativeID Yes \u0026gt; preadv2 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; preadv2 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; setitimer SYSCALLID ID, UINT16 nativeID Yes \u0026lt; setitimer SYSCALLID ID, UINT16 nativeID Yes \u0026gt; shmat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; shmat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getitimer SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getitimer SYSCALLID ID, UINT16 nativeID Yes \u0026gt; removexattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; removexattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; msgget SYSCALLID ID, UINT16 nativeID Yes \u0026lt; msgget SYSCALLID ID, UINT16 nativeID Yes \u0026gt; spu_create SYSCALLID ID, UINT16 nativeID Yes \u0026lt; spu_create SYSCALLID ID, UINT16 nativeID Yes \u0026gt; capget SYSCALLID ID, UINT16 nativeID Yes \u0026lt; capget SYSCALLID ID, UINT16 nativeID Yes \u0026gt; rt_sigsuspend SYSCALLID ID, UINT16 nativeID Yes \u0026lt; rt_sigsuspend SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mseal SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mseal SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fanotify_init SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fanotify_init SYSCALLID ID, UINT16 nativeID Yes \u0026gt; readdir SYSCALLID ID, UINT16 nativeID Yes \u0026lt; readdir SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getxattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getxattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mq_timedreceive SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mq_timedreceive SYSCALLID ID, UINT16 nativeID Yes \u0026gt; nice SYSCALLID ID, UINT16 nativeID Yes \u0026lt; nice SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fsopen SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fsopen SYSCALLID ID, UINT16 nativeID Yes \u0026gt; rt_sigpending SYSCALLID ID, UINT16 nativeID Yes \u0026lt; rt_sigpending SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sysfs SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sysfs SYSCALLID ID, UINT16 nativeID Yes \u0026gt; acct SYSCALLID ID, UINT16 nativeID Yes \u0026lt; acct SYSCALLID ID, UINT16 nativeID Yes \u0026gt; setfsgid SYSCALLID ID, UINT16 nativeID Yes \u0026lt; setfsgid SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sync SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sync SYSCALLID ID, UINT16 nativeID Yes \u0026gt; clock_adjtime SYSCALLID ID, UINT16 nativeID Yes \u0026lt; clock_adjtime SYSCALLID ID, UINT16 nativeID Yes \u0026gt; io_getevents SYSCALLID ID, UINT16 nativeID Yes \u0026lt; io_getevents SYSCALLID ID, UINT16 nativeID Yes \u0026gt; query_module SYSCALLID ID, UINT16 nativeID Yes \u0026lt; query_module SYSCALLID ID, UINT16 nativeID Yes \u0026gt; remap_file_pages SYSCALLID ID, UINT16 nativeID Yes \u0026lt; remap_file_pages SYSCALLID ID, UINT16 nativeID Yes \u0026gt; rt_sigprocmask SYSCALLID ID, UINT16 nativeID Yes \u0026lt; rt_sigprocmask SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mincore SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mincore SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getpgid SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getpgid SYSCALLID ID, UINT16 nativeID Yes \u0026gt; msgsnd SYSCALLID ID, UINT16 nativeID Yes \u0026lt; msgsnd SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_getparam SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_getparam SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getgroups SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getgroups SYSCALLID ID, UINT16 nativeID Yes \u0026gt; ustat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; ustat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; uname SYSCALLID ID, UINT16 nativeID Yes \u0026lt; uname SYSCALLID ID, UINT16 nativeID Yes \u0026gt; epoll_ctl SYSCALLID ID, UINT16 nativeID Yes \u0026lt; epoll_ctl SYSCALLID ID, UINT16 nativeID Yes \u0026gt; lgetxattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; lgetxattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; _sysctl SYSCALLID ID, UINT16 nativeID Yes \u0026lt; _sysctl SYSCALLID ID, UINT16 nativeID Yes \u0026gt; rt_sigtimedwait SYSCALLID ID, UINT16 nativeID Yes \u0026lt; rt_sigtimedwait SYSCALLID ID, UINT16 nativeID Yes \u0026gt; flistxattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; flistxattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pkey_alloc SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pkey_alloc SYSCALLID ID, UINT16 nativeID Yes \u0026gt; time SYSCALLID ID, UINT16 nativeID Yes \u0026lt; time SYSCALLID ID, UINT16 nativeID Yes \u0026gt; kcmp SYSCALLID ID, UINT16 nativeID Yes \u0026lt; kcmp SYSCALLID ID, UINT16 nativeID Yes \u0026gt; epoll_pwait SYSCALLID ID, UINT16 nativeID Yes \u0026lt; epoll_pwait SYSCALLID ID, UINT16 nativeID Yes \u0026gt; oldlstat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; oldlstat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_setscheduler SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_setscheduler SYSCALLID ID, UINT16 nativeID Yes \u0026gt; statfs SYSCALLID ID, UINT16 nativeID Yes \u0026lt; statfs SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fdatasync SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fdatasync SYSCALLID ID, UINT16 nativeID Yes \u0026gt; set_robust_list SYSCALLID ID, UINT16 nativeID Yes \u0026lt; set_robust_list SYSCALLID ID, UINT16 nativeID Yes \u0026gt; swapoff SYSCALLID ID, UINT16 nativeID Yes \u0026lt; swapoff SYSCALLID ID, UINT16 nativeID Yes \u0026gt; quotactl_fd SYSCALLID ID, UINT16 nativeID Yes \u0026lt; quotactl_fd SYSCALLID ID, UINT16 nativeID Yes \u0026gt; exit_group SYSCALLID ID, UINT16 nativeID Yes \u0026lt; exit_group SYSCALLID ID, UINT16 nativeID Yes \u0026gt; listmount SYSCALLID ID, UINT16 nativeID Yes \u0026lt; listmount SYSCALLID ID, UINT16 nativeID Yes \u0026gt; timerfd_settime SYSCALLID ID, UINT16 nativeID Yes \u0026lt; timerfd_settime SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_getscheduler SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_getscheduler SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_get_priority_min SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_get_priority_min SYSCALLID ID, UINT16 nativeID Yes \u0026gt; ftruncate SYSCALLID ID, UINT16 nativeID Yes \u0026lt; ftruncate SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pkey_free SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pkey_free SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_rr_get_interval SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_rr_get_interval SYSCALLID ID, UINT16 nativeID Yes \u0026gt; open_tree SYSCALLID ID, UINT16 nativeID Yes \u0026lt; open_tree SYSCALLID ID, UINT16 nativeID Yes \u0026gt; idle SYSCALLID ID, UINT16 nativeID Yes \u0026lt; idle SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mremap SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mremap SYSCALLID ID, UINT16 nativeID Yes \u0026gt; rt_sigaction SYSCALLID ID, UINT16 nativeID Yes \u0026lt; rt_sigaction SYSCALLID ID, UINT16 nativeID Yes \u0026gt; stime SYSCALLID ID, UINT16 nativeID Yes \u0026lt; stime SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_getattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_getattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; rt_sigqueueinfo SYSCALLID ID, UINT16 nativeID Yes \u0026lt; rt_sigqueueinfo SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sync_file_range SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sync_file_range SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mq_unlink SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mq_unlink SYSCALLID ID, UINT16 nativeID Yes \u0026gt; alarm SYSCALLID ID, UINT16 nativeID Yes \u0026lt; alarm SYSCALLID ID, UINT16 nativeID Yes \u0026gt; inotify_rm_watch SYSCALLID ID, UINT16 nativeID Yes \u0026lt; inotify_rm_watch SYSCALLID ID, UINT16 nativeID Yes \u0026gt; lsetxattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; lsetxattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; timer_delete SYSCALLID ID, UINT16 nativeID Yes \u0026lt; timer_delete SYSCALLID ID, UINT16 nativeID Yes \u0026gt; msync SYSCALLID ID, UINT16 nativeID Yes \u0026lt; msync SYSCALLID ID, UINT16 nativeID Yes \u0026gt; timer_settime SYSCALLID ID, UINT16 nativeID Yes \u0026lt; timer_settime SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sigprocmask SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sigprocmask SYSCALLID ID, UINT16 nativeID Yes \u0026gt; lremovexattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; lremovexattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fremovexattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fremovexattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_setaffinity SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_setaffinity SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fsetxattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fsetxattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; settimeofday SYSCALLID ID, UINT16 nativeID Yes \u0026lt; settimeofday SYSCALLID ID, UINT16 nativeID Yes \u0026gt; gettimeofday SYSCALLID ID, UINT16 nativeID Yes \u0026lt; gettimeofday SYSCALLID ID, UINT16 nativeID Yes \u0026gt; io_setup SYSCALLID ID, UINT16 nativeID Yes \u0026lt; io_setup SYSCALLID ID, UINT16 nativeID Yes \u0026gt; llistxattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; llistxattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fsync SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fsync SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pidfd_send_signal SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pidfd_send_signal SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getrandom SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getrandom SYSCALLID ID, UINT16 nativeID Yes \u0026gt; s390_sthyi SYSCALLID ID, UINT16 nativeID Yes \u0026lt; s390_sthyi SYSCALLID ID, UINT16 nativeID Yes \u0026gt; io_destroy SYSCALLID ID, UINT16 nativeID Yes \u0026lt; io_destroy SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sigaltstack SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sigaltstack SYSCALLID ID, UINT16 nativeID Yes \u0026gt; riscv_flush_icache SYSCALLID ID, UINT16 nativeID Yes \u0026lt; riscv_flush_icache SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mount_setattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mount_setattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getpgrp SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getpgrp SYSCALLID ID, UINT16 nativeID Yes \u0026gt; vhangup SYSCALLID ID, UINT16 nativeID Yes \u0026lt; vhangup SYSCALLID ID, UINT16 nativeID Yes \u0026gt; set_tid_address SYSCALLID ID, UINT16 nativeID Yes \u0026lt; set_tid_address SYSCALLID ID, UINT16 nativeID Yes \u0026gt; timer_create SYSCALLID ID, UINT16 nativeID Yes \u0026lt; timer_create SYSCALLID ID, UINT16 nativeID Yes \u0026gt; timer_gettime SYSCALLID ID, UINT16 nativeID Yes \u0026lt; timer_gettime SYSCALLID ID, UINT16 nativeID Yes \u0026gt; timer_getoverrun SYSCALLID ID, UINT16 nativeID Yes \u0026lt; timer_getoverrun SYSCALLID ID, UINT16 nativeID Yes \u0026gt; clock_settime SYSCALLID ID, UINT16 nativeID Yes \u0026lt; clock_settime SYSCALLID ID, UINT16 nativeID Yes \u0026gt; clock_getres SYSCALLID ID, UINT16 nativeID Yes \u0026lt; clock_getres SYSCALLID ID, UINT16 nativeID Yes \u0026gt; utimes SYSCALLID ID, UINT16 nativeID Yes \u0026lt; utimes SYSCALLID ID, UINT16 nativeID Yes \u0026gt; vm86 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; vm86 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; lsm_set_self_attr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; lsm_set_self_attr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; clock_nanosleep SYSCALLID ID, UINT16 nativeID Yes \u0026lt; clock_nanosleep SYSCALLID ID, UINT16 nativeID Yes \u0026gt; futimesat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; futimesat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; signal SYSCALLID ID, UINT16 nativeID Yes \u0026lt; signal SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mq_open SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mq_open SYSCALLID ID, UINT16 nativeID Yes \u0026gt; keyctl SYSCALLID ID, UINT16 nativeID Yes \u0026lt; keyctl SYSCALLID ID, UINT16 nativeID Yes \u0026gt; ioprio_set SYSCALLID ID, UINT16 nativeID Yes \u0026lt; ioprio_set SYSCALLID ID, UINT16 nativeID Yes \u0026gt; landlock_add_rule SYSCALLID ID, UINT16 nativeID Yes \u0026lt; landlock_add_rule SYSCALLID ID, UINT16 nativeID Yes \u0026gt; add_key SYSCALLID ID, UINT16 nativeID Yes \u0026lt; add_key SYSCALLID ID, UINT16 nativeID Yes \u0026gt; set_thread_area SYSCALLID ID, UINT16 nativeID Yes \u0026lt; set_thread_area SYSCALLID ID, UINT16 nativeID Yes \u0026gt; ioprio_get SYSCALLID ID, UINT16 nativeID Yes \u0026lt; ioprio_get SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sync_file_range2 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sync_file_range2 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; ioperm SYSCALLID ID, UINT16 nativeID Yes \u0026lt; ioperm SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sigaction SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sigaction SYSCALLID ID, UINT16 nativeID Yes \u0026gt; inotify_add_watch SYSCALLID ID, UINT16 nativeID Yes \u0026lt; inotify_add_watch SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fallocate SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fallocate SYSCALLID ID, UINT16 nativeID Yes \u0026gt; get_thread_area SYSCALLID ID, UINT16 nativeID Yes \u0026lt; get_thread_area SYSCALLID ID, UINT16 nativeID Yes \u0026gt; readlinkat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; readlinkat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; name_to_handle_at SYSCALLID ID, UINT16 nativeID Yes \u0026lt; name_to_handle_at SYSCALLID ID, UINT16 nativeID Yes \u0026gt; perf_event_open SYSCALLID ID, UINT16 nativeID Yes \u0026lt; perf_event_open SYSCALLID ID, UINT16 nativeID Yes \u0026gt; kexec_load SYSCALLID ID, UINT16 nativeID Yes \u0026lt; kexec_load SYSCALLID ID, UINT16 nativeID Yes \u0026gt; truncate SYSCALLID ID, UINT16 nativeID Yes \u0026lt; truncate SYSCALLID ID, UINT16 nativeID Yes \u0026gt; faccessat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; faccessat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mq_timedsend SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mq_timedsend SYSCALLID ID, UINT16 nativeID Yes \u0026gt; restart_syscall SYSCALLID ID, UINT16 nativeID Yes \u0026lt; restart_syscall SYSCALLID ID, UINT16 nativeID Yes \u0026gt; map_shadow_stack SYSCALLID ID, UINT16 nativeID Yes \u0026lt; map_shadow_stack SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pselect6 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pselect6 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; epoll_ctl_old SYSCALLID ID, UINT16 nativeID Yes \u0026lt; epoll_ctl_old SYSCALLID ID, UINT16 nativeID Yes \u0026gt; get_robust_list SYSCALLID ID, UINT16 nativeID Yes \u0026lt; get_robust_list SYSCALLID ID, UINT16 nativeID Yes \u0026gt; tee SYSCALLID ID, UINT16 nativeID Yes \u0026lt; tee SYSCALLID ID, UINT16 nativeID Yes \u0026gt; vmsplice SYSCALLID ID, UINT16 nativeID Yes \u0026lt; vmsplice SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getcpu SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getcpu SYSCALLID ID, UINT16 nativeID Yes \u0026gt; utimensat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; utimensat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; rseq SYSCALLID ID, UINT16 nativeID Yes \u0026lt; rseq SYSCALLID ID, UINT16 nativeID Yes \u0026gt; timerfd_gettime SYSCALLID ID, UINT16 nativeID Yes \u0026lt; timerfd_gettime SYSCALLID ID, UINT16 nativeID Yes \u0026gt; syncfs SYSCALLID ID, UINT16 nativeID Yes \u0026lt; syncfs SYSCALLID ID, UINT16 nativeID Yes \u0026gt; msgctl SYSCALLID ID, UINT16 nativeID Yes \u0026lt; msgctl SYSCALLID ID, UINT16 nativeID Yes \u0026gt; io_submit SYSCALLID ID, UINT16 nativeID Yes \u0026lt; io_submit SYSCALLID ID, UINT16 nativeID Yes \u0026gt; oldolduname SYSCALLID ID, UINT16 nativeID Yes \u0026lt; oldolduname SYSCALLID ID, UINT16 nativeID Yes \u0026gt; shmdt SYSCALLID ID, UINT16 nativeID Yes \u0026lt; shmdt SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_getaffinity SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_getaffinity SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fstatat64 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fstatat64 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; socketcall SYSCALLID ID, UINT16 nativeID Yes \u0026lt; socketcall SYSCALLID ID, UINT16 nativeID Yes \u0026gt; waitid SYSCALLID ID, UINT16 nativeID Yes \u0026lt; waitid SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sgetmask SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sgetmask SYSCALLID ID, UINT16 nativeID Yes \u0026gt; io_cancel SYSCALLID ID, UINT16 nativeID Yes \u0026lt; io_cancel SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_setparam SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_setparam SYSCALLID ID, UINT16 nativeID Yes \u0026gt; cachestat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; cachestat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_setattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_setattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; ssetmask SYSCALLID ID, UINT16 nativeID Yes \u0026lt; ssetmask SYSCALLID ID, UINT16 nativeID Yes \u0026gt; _newselect SYSCALLID ID, UINT16 nativeID Yes \u0026lt; _newselect SYSCALLID ID, UINT16 nativeID Yes \u0026gt; setfsuid SYSCALLID ID, UINT16 nativeID Yes \u0026lt; setfsuid SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sigpending SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sigpending SYSCALLID ID, UINT16 nativeID Yes \u0026gt; wait4 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; wait4 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; process_mrelease SYSCALLID ID, UINT16 nativeID Yes \u0026lt; process_mrelease SYSCALLID ID, UINT16 nativeID Yes \u0026gt; waitpid SYSCALLID ID, UINT16 nativeID Yes \u0026lt; waitpid SYSCALLID ID, UINT16 nativeID Yes \u0026gt; arch_prctl SYSCALLID ID, UINT16 nativeID Yes \u0026lt; arch_prctl SYSCALLID ID, UINT16 nativeID Yes \u0026gt; rt_sigreturn SYSCALLID ID, UINT16 nativeID Yes \u0026lt; rt_sigreturn SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fadvise64 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fadvise64 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; msgrcv SYSCALLID ID, UINT16 nativeID Yes \u0026lt; msgrcv SYSCALLID ID, UINT16 nativeID Yes \u0026gt; move_mount SYSCALLID ID, UINT16 nativeID Yes \u0026lt; move_mount SYSCALLID ID, UINT16 nativeID Yes \u0026gt; lookup_dcookie SYSCALLID ID, UINT16 nativeID Yes \u0026lt; lookup_dcookie SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fspick SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fspick SYSCALLID ID, UINT16 nativeID Yes \u0026gt; shmget SYSCALLID ID, UINT16 nativeID Yes \u0026lt; shmget SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fsmount SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fsmount SYSCALLID ID, UINT16 nativeID Yes \u0026gt; epoll_pwait2 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; epoll_pwait2 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; move_pages SYSCALLID ID, UINT16 nativeID Yes \u0026lt; move_pages SYSCALLID ID, UINT16 nativeID Yes \u0026gt; shmctl SYSCALLID ID, UINT16 nativeID Yes \u0026lt; shmctl SYSCALLID ID, UINT16 nativeID Yes \u0026gt; memfd_secret SYSCALLID ID, UINT16 nativeID Yes \u0026lt; memfd_secret SYSCALLID ID, UINT16 nativeID Yes \u0026gt; landlock_restrict_self SYSCALLID ID, UINT16 nativeID Yes \u0026lt; landlock_restrict_self SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sched_get_priority_max SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sched_get_priority_max SYSCALLID ID, UINT16 nativeID Yes \u0026gt; sys_debug_setcontext SYSCALLID ID, UINT16 nativeID Yes \u0026lt; sys_debug_setcontext SYSCALLID ID, UINT16 nativeID Yes \u0026gt; kexec_file_load SYSCALLID ID, UINT16 nativeID Yes \u0026lt; kexec_file_load SYSCALLID ID, UINT16 nativeID Yes \u0026gt; process_madvise SYSCALLID ID, UINT16 nativeID Yes \u0026lt; process_madvise SYSCALLID ID, UINT16 nativeID Yes \u0026gt; landlock_create_ruleset SYSCALLID ID, UINT16 nativeID Yes \u0026lt; landlock_create_ruleset SYSCALLID ID, UINT16 nativeID Yes \u0026gt; rt_tgsigqueueinfo SYSCALLID ID, UINT16 nativeID Yes \u0026lt; rt_tgsigqueueinfo SYSCALLID ID, UINT16 nativeID Yes \u0026gt; migrate_pages SYSCALLID ID, UINT16 nativeID Yes \u0026lt; migrate_pages SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fstatfs64 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fstatfs64 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pwritev2 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pwritev2 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; mbind SYSCALLID ID, UINT16 nativeID Yes \u0026lt; mbind SYSCALLID ID, UINT16 nativeID Yes \u0026gt; modify_ldt SYSCALLID ID, UINT16 nativeID Yes \u0026lt; modify_ldt SYSCALLID ID, UINT16 nativeID Yes \u0026gt; gettid SYSCALLID ID, UINT16 nativeID Yes \u0026lt; gettid SYSCALLID ID, UINT16 nativeID Yes \u0026gt; statx SYSCALLID ID, UINT16 nativeID Yes \u0026lt; statx SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getpriority SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getpriority SYSCALLID ID, UINT16 nativeID Yes \u0026gt; io_pgetevents SYSCALLID ID, UINT16 nativeID Yes \u0026lt; io_pgetevents SYSCALLID ID, UINT16 nativeID Yes \u0026gt; listxattrat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; listxattrat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; set_mempolicy_home_node SYSCALLID ID, UINT16 nativeID Yes \u0026lt; set_mempolicy_home_node SYSCALLID ID, UINT16 nativeID Yes \u0026gt; readahead SYSCALLID ID, UINT16 nativeID Yes \u0026lt; readahead SYSCALLID ID, UINT16 nativeID Yes \u0026gt; futex_waitv SYSCALLID ID, UINT16 nativeID Yes \u0026lt; futex_waitv SYSCALLID ID, UINT16 nativeID Yes \u0026gt; epoll_wait_old SYSCALLID ID, UINT16 nativeID Yes \u0026lt; epoll_wait_old SYSCALLID ID, UINT16 nativeID Yes \u0026gt; faccessat2 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; faccessat2 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; get_mempolicy SYSCALLID ID, UINT16 nativeID Yes \u0026lt; get_mempolicy SYSCALLID ID, UINT16 nativeID Yes \u0026gt; membarrier SYSCALLID ID, UINT16 nativeID Yes \u0026lt; membarrier SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pciconfig_iobase SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pciconfig_iobase SYSCALLID ID, UINT16 nativeID Yes \u0026gt; close_range SYSCALLID ID, UINT16 nativeID Yes \u0026lt; close_range SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fanotify_mark SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fanotify_mark SYSCALLID ID, UINT16 nativeID Yes \u0026gt; open_tree_attr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; open_tree_attr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; timerfd SYSCALLID ID, UINT16 nativeID Yes \u0026lt; timerfd SYSCALLID ID, UINT16 nativeID Yes \u0026gt; s390_pci_mmio_read SYSCALLID ID, UINT16 nativeID Yes \u0026lt; s390_pci_mmio_read SYSCALLID ID, UINT16 nativeID Yes \u0026gt; s390_pci_mmio_write SYSCALLID ID, UINT16 nativeID Yes \u0026lt; s390_pci_mmio_write SYSCALLID ID, UINT16 nativeID Yes \u0026gt; s390_runtime_instr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; s390_runtime_instr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; s390_guarded_storage SYSCALLID ID, UINT16 nativeID Yes \u0026lt; s390_guarded_storage SYSCALLID ID, UINT16 nativeID Yes \u0026gt; fchmodat2 SYSCALLID ID, UINT16 nativeID Yes \u0026lt; fchmodat2 SYSCALLID ID, UINT16 nativeID Yes \u0026gt; futex_wake SYSCALLID ID, UINT16 nativeID Yes \u0026lt; futex_wake SYSCALLID ID, UINT16 nativeID Yes \u0026gt; futex_requeue SYSCALLID ID, UINT16 nativeID Yes \u0026lt; futex_requeue SYSCALLID ID, UINT16 nativeID Yes \u0026gt; futex_wait SYSCALLID ID, UINT16 nativeID Yes \u0026lt; futex_wait SYSCALLID ID, UINT16 nativeID Yes \u0026gt; switch_endian SYSCALLID ID, UINT16 nativeID Yes \u0026lt; switch_endian SYSCALLID ID, UINT16 nativeID Yes \u0026gt; multiplexer SYSCALLID ID, UINT16 nativeID Yes \u0026lt; multiplexer SYSCALLID ID, UINT16 nativeID Yes \u0026gt; oldfstat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; oldfstat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; lsm_get_self_attr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; lsm_get_self_attr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; swapcontext SYSCALLID ID, UINT16 nativeID Yes \u0026lt; swapcontext SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pciconfig_write SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pciconfig_write SYSCALLID ID, UINT16 nativeID Yes \u0026gt; rtas SYSCALLID ID, UINT16 nativeID Yes \u0026lt; rtas SYSCALLID ID, UINT16 nativeID Yes \u0026gt; pciconfig_read SYSCALLID ID, UINT16 nativeID Yes \u0026lt; pciconfig_read SYSCALLID ID, UINT16 nativeID Yes \u0026gt; subpage_prot SYSCALLID ID, UINT16 nativeID Yes \u0026lt; subpage_prot SYSCALLID ID, UINT16 nativeID Yes \u0026gt; statmount SYSCALLID ID, UINT16 nativeID Yes \u0026lt; statmount SYSCALLID ID, UINT16 nativeID Yes \u0026gt; lsm_list_modules SYSCALLID ID, UINT16 nativeID Yes \u0026lt; lsm_list_modules SYSCALLID ID, UINT16 nativeID Yes \u0026gt; uretprobe SYSCALLID ID, UINT16 nativeID Yes \u0026lt; uretprobe SYSCALLID ID, UINT16 nativeID Yes \u0026gt; removexattrat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; removexattrat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; getxattrat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; getxattrat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; setxattrat SYSCALLID ID, UINT16 nativeID Yes \u0026lt; setxattrat SYSCALLID ID, UINT16 nativeID Yes \u0026gt; file_getattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; file_getattr SYSCALLID ID, UINT16 nativeID Yes \u0026gt; file_setattr SYSCALLID ID, UINT16 nativeID Yes \u0026lt; file_setattr SYSCALLID ID, UINT16 nativeID Tracepoint events Default Dir Name Params Yes \u0026gt; switch PID next, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap Yes \u0026gt; procexit ERRNO status, ERRNO ret, SIGTYPE sig, UINT8 core, PID reaper_tid Yes \u0026gt; signaldeliver PID spid, PID dpid, SIGTYPE sig Yes \u0026gt; page_fault UINT64 addr, UINT64 ip, FLAGS32 error: PROTECTION_VIOLATION, PAGE_NOT_PRESENT, WRITE_ACCESS, READ_ACCESS, USER_FAULT, SUPERVISOR_FAULT, RESERVED_PAGE, INSTRUCTION_FETCH Plugin events Default Dir Name Params Yes \u0026gt; pluginevent UINT32 plugin_id, BYTEBUF event_data Metaevents Default Dir Name Params Yes \u0026gt; drop UINT32 ratio Yes \u0026lt; drop UINT32 ratio Yes \u0026gt; scapevent UINT32 event_type, UINT64 event_data Yes \u0026gt; procinfo UINT64 cpu_usr, UINT64 cpu_sys Yes \u0026gt; cpu_hotplug UINT32 cpu, UINT32 action Yes \u0026gt; notification CHARBUF id, CHARBUF desc Yes \u0026gt; infra CHARBUF source, CHARBUF name, CHARBUF description, CHARBUF scope Yes \u0026gt; container CHARBUF json Yes \u0026gt; useradded UINT32 uid, UINT32 gid, CHARBUF name, CHARBUF home, CHARBUF shell, CHARBUF container_id Yes \u0026gt; userdeleted UINT32 uid, UINT32 gid, CHARBUF name, CHARBUF home, CHARBUF shell, CHARBUF container_id Yes \u0026gt; groupadded UINT32 gid, CHARBUF name, CHARBUF container_id Yes \u0026gt; groupdeleted UINT32 gid, CHARBUF name, CHARBUF container_id Yes \u0026gt; asyncevent UINT32 plugin_id, CHARBUF name, BYTEBUF data ","summary":"","tags":null,"title":"Supported Events","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/rules/supported-events/"},{"category":"docs","content":"Falco v0.13.0 adds Kubernetes Audit Events to the list of supported event sources. This is in addition to the existing support for system call events. An improved implementation of audit events was introduced in Kubernetes v1.11 and it provides a log of requests and responses to kube-apiserver. Because almost all the cluster management tasks are performed through the API server, the audit log can effectively track the changes made to your cluster.\nExamples of this include:\nCreating and destroying pods, services, deployments, daemonsets, etc. Creating, updating, and removing ConfigMaps or secrets Subscribing to the changes introduced to any endpoint To cover these scenarios, additional set of falco rules have been added that monitor for notable or suspicious activity, including:\nCreating pods that are privileged, mount sensitive host paths, or use host networking. Granting overly broad permissions such as cluster-admin to users. Creating ConfigMaps with sensitive information. Once your cluster is configured with audit logging and the events are selected to be sent to falco, you can write falco rules that can read these events and send notifications for suspicious or other notable activity.\nWhat's New in Falco Since Falco 0.32.0, the Kubernetes Audit Events support has been refactored to become a plugin and is compliant to the Falco Plugin System. Previously, this feature was supported as a parallel independent stream of events that was read separately from system calls, and was matched separately against its own sets of rules.\nTo receive Kubernetes audit events, the plugin embeds a webserver that listens on a configurable port and accepts POST requests on a configurable endpoint. The posted JSON object comprises the event. The webserver embedded inside Falco to implement endpoints such as /healthz is totally unrelated and independent from the webserver of the plugin. The webserver of the plugin can be configured as part of the plugin's init configuration and open parameters.\nSee configuration page for information on how plugins can be configured in Falco, and refer to the plugin's readme for more specifics.\nThe new plugin-based implementation has been developed to be as similar as possible to the legacy K8S Audit Events feature introduced in Falco 0.13.0. However, due to technical constraints, there are few user-facing differences. Although the most up-to-date setups should work as they used to, there are few user-facing differences to be mindful of:\nK8S Audit Events support must be configured in falco.yaml through the plugins section through the plugin's init configuration and open parameters.\nIn the legacy implementation, the extraction of list of values was supported implicitly. When extracting a field for a rule condition or output, the check used to be able to extract single values or list of values, and use them with operators such as in, intersect, etc. However, the concept of \u0026quot;list\u0026quot; was totally implicity and there was no distinction between single values and lists of values with length equal to 1.\nNow, the plugin-based implementation is compliant to the new semantics supported in the libs since Falco 0.32, which allows fields to be of explicit list type. A field of list type will always extract list of values, containing one or more entries, or fail the extraction.\nFields of list type now only support the in and intersects operators. For example, checks such as ka.req.role.rules.verbs contains create would be rejected and would need to be changed in the equivalent ka.req.role.rules.verbs intersects (create).\nFailed field value extraction should now be checked with the exists operator, and not by comparing with the \u0026lt;NA\u0026gt; string.\nThe \u0026lt;NA\u0026gt; string literal is not returned anymore, neither in single-valued fields nor in list fields. In the legacy implementation, field existence was occasionally checked with expressions like ka.target.subresource != \u0026lt;NA\u0026gt;, which would now inherently be always false, because if the field was absent the string comparison ends up failing. Instead, prefer using the analogous ka.target.subresource exists, which explicitly checks for missing values\nThe /healthz endpoint of Falco cannot bind to the same port of the K8S Audit Log endpoint (e.g. /k8s-audit), due to the fact that they are now managed by two different webservers (one in Falco, one in the plugin).\nIn Falco versions 0.32.x (Falco v0.32.0, v0.32.1, and v0.32.2), Falco didn't allow the use of Syscalls and K8S Audit event sources on the same instance. Starting from version 0.33.0, Falco introduced the capability of consuming events from multiple event sources simultaneously within the same Falco instance.\nKubernetes Audit Rules Rules devoted to Kubernetes audit events are given in the default k8saudit plugin rules. When installed as a daemon, falco installs this rules file to /etc/falco/, so they are available for use.\nExample One of the rules in k8s_audit_rules.yaml is as follows:\n- list: k8s_audit_stages items: [\u0026#34;ResponseComplete\u0026#34;] # This macro selects the set of Audit Events used by the below rules. - macro: kevt condition: (jevt.value[/stage] in (k8s_audit_stages)) - macro: kmodify condition: (ka.verb in (create,update,patch)) - macro: configmap condition: ka.target.resource=configmaps - macro: contains_private_credentials condition: \u0026gt; (ka.req.configmap.obj contains \u0026#34;aws_access_key_id\u0026#34; or ka.req.configmap.obj contains \u0026#34;aws-access-key-id\u0026#34; or ka.req.configmap.obj contains \u0026#34;aws_s3_access_key_id\u0026#34; or ka.req.configmap.obj contains \u0026#34;aws-s3-access-key-id\u0026#34; or ka.req.configmap.obj contains \u0026#34;password\u0026#34; or ka.req.configmap.obj contains \u0026#34;passphrase\u0026#34;) - rule: Configmap contains private credentials desc: \u0026gt; Detect configmap operations with map containing a private credential (aws key, password, etc.) condition: kevt and configmap and modify and contains_private_credentials output: K8s configmap with private credential | user=%ka.user.name verb=%ka.verb name=%ka.req.configmap.name configmap=%ka.req.configmap.name config=%ka.req.configmap.obj priority: WARNING source: k8s_audit tags: [k8s] The Configmap contains private credentials rule checks for a ConfigMap created with possibly sensitive items, such as AWS keys or passwords.\nLet's see how the rule works in such cases. This topic assumes that Kubernetes audit logging is configured in your environment.\nCreate a ConfigMap containing AWS credentials:\napiVersion: v1 data: ui.properties: | color.good=purple color.bad=yellow allow.textmode=true access.properties: | aws_access_key_id = MY-ID aws_secret_access_key = MY-KEY kind: ConfigMap metadata: creationTimestamp: 2016-02-18T18:52:05Z name: my-config namespace: default resourceVersion: \u0026#34;516\u0026#34; selfLink: /api/v1/namespaces/default/configmaps/my-config uid: b4952dc3-d670-11e5-8cd0-68f728db1985 Creating this ConfigMap results in the following json object in the audit log:\n{ \u0026#34;kind\u0026#34;: \u0026#34;Event\u0026#34;, \u0026#34;apiVersion\u0026#34;: \u0026#34;audit.k8s.io/v1beta1\u0026#34;, \u0026#34;metadata\u0026#34;: { \u0026#34;creationTimestamp\u0026#34;: \u0026#34;2018-10-20T00:18:28Z\u0026#34; }, \u0026#34;level\u0026#34;: \u0026#34;RequestResponse\u0026#34;, \u0026#34;timestamp\u0026#34;: \u0026#34;2018-10-20T00:18:28Z\u0026#34;, \u0026#34;auditID\u0026#34;: \u0026#34;33fa264e-1124-4252-af9e-2ce6e45fe07d\u0026#34;, \u0026#34;stage\u0026#34;: \u0026#34;ResponseComplete\u0026#34;, \u0026#34;requestURI\u0026#34;: \u0026#34;/api/v1/namespaces/default/configmaps\u0026#34;, \u0026#34;verb\u0026#34;: \u0026#34;create\u0026#34;, \u0026#34;user\u0026#34;: { \u0026#34;username\u0026#34;: \u0026#34;minikube-user\u0026#34;, \u0026#34;groups\u0026#34;: [ \u0026#34;system:masters\u0026#34;, \u0026#34;system:authenticated\u0026#34; ] }, \u0026#34;sourceIPs\u0026#34;: [ \u0026#34;192.168.99.1\u0026#34; ], \u0026#34;objectRef\u0026#34;: { \u0026#34;resource\u0026#34;: \u0026#34;configmaps\u0026#34;, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;my-config\u0026#34;, \u0026#34;uid\u0026#34;: \u0026#34;b4952dc3-d670-11e5-8cd0-68f728db1985\u0026#34;, \u0026#34;apiVersion\u0026#34;: \u0026#34;v1\u0026#34; }, \u0026#34;responseStatus\u0026#34;: { \u0026#34;metadata\u0026#34;: { }, \u0026#34;code\u0026#34;: 201 }, \u0026#34;requestObject\u0026#34;: { \u0026#34;kind\u0026#34;: \u0026#34;ConfigMap\u0026#34;, \u0026#34;apiVersion\u0026#34;: \u0026#34;v1\u0026#34;, \u0026#34;metadata\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;my-config\u0026#34;, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;selfLink\u0026#34;: \u0026#34;/api/v1/namespaces/default/configmaps/my-config\u0026#34;, \u0026#34;uid\u0026#34;: \u0026#34;b4952dc3-d670-11e5-8cd0-68f728db1985\u0026#34;, \u0026#34;creationTimestamp\u0026#34;: \u0026#34;2016-02-18T18:52:05Z\u0026#34; }, \u0026#34;data\u0026#34;: { \u0026#34;access.properties\u0026#34;: \u0026#34;aws_access_key_id = MY-ID\\naws_secret_access_key = MY-KEY\\n\u0026#34;, \u0026#34;ui.properties\u0026#34;: \u0026#34;color.good=purple\\ncolor.bad=yellow\\nallow.textmode=true\\n\u0026#34; } }, \u0026#34;responseObject\u0026#34;: { \u0026#34;kind\u0026#34;: \u0026#34;ConfigMap\u0026#34;, \u0026#34;apiVersion\u0026#34;: \u0026#34;v1\u0026#34;, \u0026#34;metadata\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;my-config\u0026#34;, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;selfLink\u0026#34;: \u0026#34;/api/v1/namespaces/default/configmaps/my-config\u0026#34;, \u0026#34;uid\u0026#34;: \u0026#34;ab04e510-d3fd-11e8-8645-080027728ac4\u0026#34;, \u0026#34;resourceVersion\u0026#34;: \u0026#34;45437\u0026#34;, \u0026#34;creationTimestamp\u0026#34;: \u0026#34;2018-10-20T00:18:28Z\u0026#34; }, \u0026#34;data\u0026#34;: { \u0026#34;access.properties\u0026#34;: \u0026#34;aws_access_key_id = MY-ID\\naws_secret_access_key = MY-KEY\\n\u0026#34;, \u0026#34;ui.properties\u0026#34;: \u0026#34;color.good=purple\\ncolor.bad=yellow\\nallow.textmode=true\\n\u0026#34; } }, \u0026#34;requestReceivedTimestamp\u0026#34;: \u0026#34;2018-10-20T00:18:28.420807Z\u0026#34;, \u0026#34;stageTimestamp\u0026#34;: \u0026#34;2018-10-20T00:18:28.428398Z\u0026#34;, \u0026#34;annotations\u0026#34;: { \u0026#34;authorization.k8s.io/decision\u0026#34;: \u0026#34;allow\u0026#34;, \u0026#34;authorization.k8s.io/reason\u0026#34;: \u0026#34;\u0026#34; } } When the ConfigMap contains private credentials, the rule uses the following fields in the given order:\nkevt: Checks whether the stage property of the object is present in the k8s_audit_stages list.\nconfigmap: Checks whether the value of the objectRef \u0026gt; resource property equals to \u0026quot;configmap\u0026quot;.\nkmodify: Checks whether the value of verb is one of the following: create,update,patch.\ncontains-private-credentials: Search the ConfigMap contents at requestObject \u0026gt; data for any of the sensitive strings named in the contains_private_credentials macro.\nIf they do, a falco alert is generated:\n17:18:28.428398080: Warning K8s ConfigMap with private credential (user=minikube-user verb=create configmap=my-config config={\u0026#34;access.properties\u0026#34;:\u0026#34;aws_access_key_id = MY-ID\\naws_secret_access_key = MY-KEY\\n\u0026#34;, \u0026#34;ui.properties\u0026#34;:\u0026#34;color.good=purple\\ncolor.bad=yellow\\nallow.textmode=true\\n\u0026#34;}) The output string is used to print essential information about the audit event, including:\nuser: %ka.user.name verb: %ka.verb ConfigMap name: %ka.req.configmap.name ConfigMap contents: %ka.req.configmap.obj Enabling Kubernetes Audit Logs To enable Kubernetes audit logs, you need to change the arguments to the kube-apiserver process to add --audit-policy-file and --audit-webhook-config-file arguments and provide files that implement an audit policy/webhook configuration.\nIt is beyond the scope of Falco documentation to give a detailed description of how to do this, but this step-by-step guide will show you how to configure kubernetes audit logs on minikube and deploy Falco. Managed Kubernetes providers will usually provide a mechanism to configure the audit system.\nDynamic Audit Webhooks were \u0026lt;a href=\u0026quot;https://github.com/kubernetes/kubernetes/pull/91502\u0026quot;\u0026gt;removed\u0026lt;/a\u0026gt; from Kubernetes. However, static audit configuration continues to work. ","summary":"","tags":null,"title":"Kubernetes Audit Events","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/event-sources/plugins/kubernetes-audit/"},{"category":"docs","content":" Falco consumes streams of events and evaluates them against a set of security rules to detect abnormal behavior. By default, Falco is pre-configured to consume events from the Linux Kernel. This scenario requires Falco to be privileged, and depending on the kernel version installed on the host, a driver needs to be installed.\nFor other installation scenarios, such as consuming cloud events or other data sources using plugins, please refer to the Plugins section.\nThere are two main methods to install Falco on your host using the released Falco packages:\nRPM or DEB package (includes Systemd setup): For instructions, refer to the Install on a host (DEB, RPM) page. Tarball archive: This method is detailed on this page. System requirements Falco runs on Linux and is available for the x86_64 and aarch64 architectures. Falco with its bundled plugins requires GLIBC 2.28 or newer. You can check your system's GLIBC version by running ldd --version.\nInstall In these steps, we are targeting a Debian-like system on x86_64 architecture. You can easily extrapolate similar steps for other distros or architectures.\nDownload the latest binary:\ncurl -L -O https://download.falco.org/packages/bin/x86_64/falco-0.43.0-x86_64.tar.gz Install Falco:\ntar -xvf falco-0.43.0-x86_64.tar.gz cp -R falco-0.43.0-x86_64/* / Install some required dependencies that are needed to build the kernel module and the eBPF probe. If you want to use other sources like the modern eBPF probe or plugins, you can skip this step.\napt update -y apt install -y dkms make linux-headers-$(uname -r) # If you use falcoctl driver loader to build the eBPF probe locally you need also clang toolchain apt install -y clang llvm Use the falcoctl driver tool to configure Falco and install the kernel module or the eBPF probe. If you want to use other sources like the modern eBPF probe or plugins, you can skip this step.\nTo install the driver, write and execute permissions on the /tmp directory are required, since falcoctl will try to create and execute a script from there.\n# If you want to use the kernel module, configure Falco for it falcoctl driver config --type kmod # If you want to use the eBPF probe, configure Falco for it falcoctl driver config --type ebpf # Install the chosen driver falcoctl driver install By default, the falcoctl driver install command tries to download a prebuilt driver from the official Falco download s3 bucket. If a driver is found, it is inserted into ${HOME}/.falco/. Otherwise, the script tries to compile the driver locally; for this reason, you need the dependencies in step [3].\nYou can use the environment variable FALCOCTL_DRIVER_REPOS to override the default repository URL for prebuilt drivers. The URL must not have a trailing slash, i.e., https://myhost.mydomain.com or, if the server has a subdirectory structure, https://myhost.mydomain.com/drivers. The drivers must be hosted with the following structure:\n/${driver_version}/${arch}/falco_${target}_${kernelrelease}_${kernelversion}.[ko|o] where ko and o stand for Kernel module and eBPF probe, respectively. This is an example:\n/7.0.0+driver/x86_64/falco_amazonlinux2022_5.10.75-82.359.amzn2022.x86_64_1.ko If you wish to print some debug info, you can use:\n# If you want to use the kernel module, configure Falco for it falcoctl driver printenv Manual Systemd setup The Falco .tar.gz archive doesn't include the Systemd setup. If you want to enable Falco to start automatically at boot time, you can still download systemd files from the Falco repo and place them in the /lib/systemd/system directory. Finally, you can follow the same instructions for enabling Systemd manually under the Install on a host (DEB, RPM) section.\nConfiguration The Falco configuration file is located at /etc/falco/falco.yaml. You can edit it to customize Falco's behavior.\nSince Falco 0.38.0, a new config key, config_files, allows the user to load additional configuration files to override main config entries; it allows users to keep local customization between Falco upgrades. Its default value points to a new folder, /etc/falco/config.d/, that gets installed by Falco and will be processed to look for local configuration files.\nYou can also override the default configuration by passing options to the falco binary. For example, to force the eBPF probe or the kernel module:\n# Force eBPF probe falco -o engine.kind=ebpf # Force kernel module falco -o engine.kind=kmod Hot Reload By default, with the watch_config_files configuration option enabled, Falco automatically monitors changes to configuration and rule files. When these files are modified, Falco will automatically reload the updated configuration without requiring a restart.\nIf this option is disabled, you can manually reload the configuration by sending a SIGHUP signal to the Falco process. To do this, use the following command:\nkill -1 $(pidof falco) Upgrade If you are using the Kernel Module driver, please remove it with root privileges before upgrading Falco to avoid issues during the upgrade.\nrmmod falco When utilizing the eBPF probe driver, although not strictly required, you can remove the corresponding previous object files:\nrm /root/.falco/*.o With Modern eBPF, there is no requirement when updating Falco, as the driver is bundled within the Falco binary.\nOnce the driver is removed, ensure the falco daemon is not running, then you can follow the same steps as the Install section.\nUninstall For the Falco binary, we don't provide specific update paths; you just have to remove files installed by the old tar.gz.\n","summary":"","tags":null,"title":"Install on a host (tarball)","url":"https://v0-43--falcosecurity.netlify.app/docs/setup/tarball/"},{"category":"docs","content":"Falco's configuration file is a YAML file containing a collection of key: value or key: [value list] pairs. Depending on your installation type the configuration file could be located in /etc/falco/falco.yaml or loaded as a configmap in Kubernetes deployments.\nThe full list of configuration items is documented in the file itself that you can find in your Falco distribution or in the Falco repository.\nAny configuration option can be overridden on the command line via the -o/--option key=value flag. For key: [value list] options, you can specify individual list items using --option key.subkey=value.\nIf a configuration entry (e.g. key.subkey) is a list you can override a specific entry by index, e.g.: --option key.subkey[0]=value. Since Falco 0.38.0 you can also append new elements to a list by adding --option key.subkey[]=value and/or --option key.subkey[].newitem=value.\nconfig_files Since Falco 0.38.0 you can also load additional configuration files after the main one with the config_files configuration entry, which can accept both files and directories. By default this option contains the /etc/falco/config.d directory.\nMerge strategy Since Falco 0.41.0, it is possible to specify a merge strategy for each entry provided in the config_files option. The loading of these files is assumed to happen after the main config file has been processed and then in the order they are specified. If a folder is specified, the files within that path are loaded in lexicographical order, and the merge strategy is applied for all files within that path. There are three merge strategies available, with append being the default merge strategy.\nappend\nExisting sequence keys will be appended Existing scalar keys will be overridden Non-existing keys will be added override\nExisting keys will be overridden Non-existing keys will be added add-only\nExisting keys will be ignored Non-existing keys will be added To utilize these merge strategies in the config_files option, add the strategy alongside the path:\nconfig_files: - /etc/falco/config.d - path: /etc/falco/config.append.d/ strategy: append - path: /etc/falco/extra_config.yaml strategy: add-only Important: Configuration merging occurs only at the root key level, not for nested keys. This means that if a configuration file in config.d/ contains a root-level key (e.g., engine:), the entire section from the main falco.yaml will be replaced, not merged.\nFor example, if you have engine-falcoctl.yaml in /etc/falco/config.d/ that sets the engine.kind option, and you try to modify engine.buf_size_preset in /etc/falco/falco.yaml, your change will be ignored because the entire engine: section is overridden by the file in config.d/.\nTo modify nested configuration options, you should either:\nEdit the file in config.d/ that contains the root key you want to modify Or remove/rename that file from config.d/ and make all changes directly in falco.yaml ","summary":"","tags":["Falco Daemon","falco.yaml","rules files"],"title":"Falco Configuration Options","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/daemon/config-options/"},{"category":"docs","content":"A Falco rule’s condition defines the filter that determines which events are detected by the rule. This condition is a boolean expression that evaluates to true or false for each event. If it evaluates to true, the rule triggers and generates an alert.\nA condition can be viewed as a sequence of comparisons, each joined by logical operators. Parentheses can be used to define precedence. Each comparison uses a comparison operator between a field (on the left side), extracted from the input event, and a static or computed value (on the right side). You can also apply transformers to the field to modify its extracted values before comparison.\nThe set of fields available depends on the data source. For simplicity, this page focuses on syscalls, as they are among the most common.\nFor example, the following condition triggers for each execution of cat or grep:\nevt.type = execve and (proc.name = cat or proc.name = grep) Operators You can use the below operators in Falco rule conditions.\nLogical operators Operators Description and Logical AND operator to connect two or more comparisons (ie. evt.type = open and fd.typechar='f'). or Logical OR operator to connect two or more comparisons (ie. proc.name = bash or proc.name = zsh). not Logical NOT operator to negate a comparison (ie. not proc.name = bash). Comparison operators Operators Description =, != Equality and inequality operators. \u0026lt;=, \u0026lt;, \u0026gt;=, \u0026gt; Comparison operators for numeric values. contains, bcontains, icontains Strings are evaluated to be true if a string contains another. For flags, contains evaluates to true if the specified flag is set. For example: proc.cmdline contains \u0026quot;-jar\u0026quot;, evt.arg.flags contains O_TRUNC. The icontains variant works similarly but is case-insensitive. The bcontains variant allows byte matching against a raw string of bytes, taking a hexadecimal string as input. For example: evt.buffer bcontains CAFEBABE endswith Checks if a string ends with a given suffix. exists Checks whether a field is set. Example: k8s.pod.name exists. glob Evaluates standard glob patterns. Example: fd.name glob \u0026quot;/home/*/.ssh/*\u0026quot;. in Evaluates whether the first set is completely contained in the second set. Example: (b,c,d) in (a,b,c) is FALSE because d is not found in (a,b,c). intersects Evaluates whether the first set has at least one element in common with the second set. Example: (b,c,d) intersects (a,b,c) is TRUE because both sets contain b and c. pmatch Compares a file path against a set of file or directory prefixes. Example: fd.name pmatch (/tmp/hello) evaluates to true for /tmp/hello, /tmp/hello/world but not /tmp/hello_world. More details in the below section. regex Checks whether a string field matches a regular expression. The regex engine is Google RE2 configured in POSIX mode, which restricts patterns to POSIX extended (egrep) syntax (backreferences are not supported). Note that regex can be considerably slower than simpler string operations. The regex operator performs a full match only, not a partial match (i.e., anchored to both the beginning and the end). Example: fd.name regex '[a-z]*/proc/[0-9]+/cmdline'. startswith, bstartswith Checks if a string starts with a given prefix. The bstartswith variant allows byte matching against a raw string of bytes, taking a hexadecimal string as input. For example: evt.buffer bstartswith 012AB3CC. pmatch operator pmatch checks if any given path prefix matches a filesystem path in Falco fields like fd.name, evt.rawarg.path, or fs.path.name. For example:\nfd.name pmatch (/var/run, /var/spool, /etc, /boot) If fd.name is /var/spool/maillog, this expression is true; if it is /opt/data/file.txt, it is false. Internally, pmatch builds a tree-like structure from the right-hand side paths and traverses it with the left-hand side path components, returning true at the first matching leaf.\npmatch can also include glob wildcards:\nfd.name pmatch (/var/*/*.txt, /etc, /boot) This still performs a prefix match. Unlike glob, which must fully match the path, pmatch succeeds if the path starts with one of the specified prefixes. Hence, fd.name pmatch (/var/*) matches /var/run/file.txt, while fd.name glob /var/* does not. Wildcards do not cross directory separators (see glob.7).\nTransformers Falco supports basic transformations on fields within rule conditions. For instance, if you want to check for a case-insensitive process name, you can use:\ntolower(proc.name) = bash The following transform operators are supported:\nTransformer Description tolower(\u0026lt;field\u0026gt;) Converts the input field to lowercase. toupper(\u0026lt;field\u0026gt;) Converts the input field to uppercase. b64(\u0026lt;field\u0026gt;) Decodes the input field from Base64. basename(\u0026lt;field\u0026gt;) Extracts the filename without its directory path from the input field. Unlike the Unix basename program, basename() in Falco returns \u0026quot;\u0026quot; if no filename is present. For example, basename(proc.exepath) is \u0026quot;cat\u0026quot; for /usr/bin/cat but \u0026quot;\u0026quot; for /usr/bin/. len(\u0026lt;field\u0026gt;) Returns the length of the field: for LIST fields, the number of elements; for CHARBUF fields, the number of characters; and for BYTEBUF fields, the number of bytes. Field evaluation (for right-hand side of comparisons) Falco also lets you compare field values with other field values by using the val() special transformer on the right-hand side of a comparison. For instance, to detect processes that have the same name as their parent:\nproc.name = val(proc.pname) Similarly, using transformations on both sides is supported:\ntolower(proc.name) = tolower(proc.pname) Syscall event types, direction, and args The evt.dir field, as well as the concept of \u0026quot;direction\u0026quot;, have been deprecated in Falco 0.42.0 and will be removed in a future release. Until field removal and since Falco 0.42.0, specifying evt.dir='\u0026gt;' will match nothing, while specifying evt.dir='\u0026lt;' will match everything, with a warning informing the user about the deprecation. Users are encouraged to get rid of any reference to evt.dir, as its presence will result in an error at rules loading time after its removal.\nEvery syscall event includes the evt field class. Each condition you write for these events typically begins with an evt.type expression or macro. This is practical because security rules often focus on one syscall type at a time. For instance, you might consider open or openat to detect suspicious activity when files are opened, or execve to inspect newly spawned processes. You do not have to guess the syscall name—simply refer to the complete list of supported system call events for an overview of what you can use.\nEach syscall has an entry event and an exit event, tracked by the evt.dir field, also referred to as the \u0026quot;direction\u0026quot; of the system call. A value of \u0026gt; indicates entry (when the syscall is invoked), while \u0026lt; marks exit (when the call has returned). By looking at the supported system call list, you will see that events have both entry and exit forms. For example:\n\u0026gt; setuid(UID uid) \u0026lt; setuid(ERRNO res) In many cases, it is most useful to filter on exit events, because you want to know the outcome of the syscall once it has completed. For example, consider the file-opening events:\n\u0026gt; open() \u0026lt; open(FD fd, FSPATH name, FLAGS32 flags, UINT32 mode, UINT32 dev) \u0026gt; openat() \u0026lt; openat(FD fd, FD dirfd, FSRELPATH name, FLAGS32 flags, UINT32 mode, UINT32 dev) Each event has a list of arguments that you can access through evt.arg.\u0026lt;argname\u0026gt;. For instance, if you want to detect a process opening a file to overwrite it, check if the list of flags contains O_TRUNC:\nevt.type in (open, openat) and evt.dir = \u0026lt; and evt.arg.flags contains O_TRUNC Note that arguments do not necessarily match the raw parameters used in the Linux kernel; Falco may parse them in ways that make rule-writing more straightforward. By using the evt fields, you can inspect many other aspects common across different events.\nSyscall event context and metadata While the evt fields allow you to write expressive conditions, arguments and common fields alone are often insufficient for complete security rules. You might also need to consider the process context in which the event occurred, whether or not it happened inside a container, or how it correlates with Kubernetes metadata. To enable this, Falco enriches many events with additional field classes. Not all field classes are available for all events, and the list grows over time. Each field class’s documentation clarifies when those fields are expected to be present, but some are so common that rules often rely on them.\nThe proc field class gives you context about the process and thread generating a specific syscall. This information is frequently very important. For example, you can use proc.name and proc.pid, or even traverse the process hierarchy with proc.aname[\u0026lt;n\u0026gt;] and proc.apid[\u0026lt;n\u0026gt;]. You can also see which user performed the action with the user field class.\nAn example rule that detects whenever bash is executed inside a container could look like this:\nevt.type = execve and container.id != host and proc.name = bash Notice that you do not need to check the execve arguments. Once execve has returned, Falco updates the process context, so all proc.* fields refer to the new process that was just spawned, including command line, executable path, arguments, and so on.\n","summary":"","tags":null,"title":"Condition Syntax","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/conditions/"},{"category":"docs","content":"In this scenario, you will learn how to install Falco on an Ubuntu host, trigger a Falco rule by generating a suspicious event, and then examine the output.\nThis activity aims to give you a quick example of how Falco works. After you complete it, you should be able to move on to trying Falco on Kubernetes or spend some time reading some additional resources.\nPrerequisites This lab is based on installing Falco on a virtual machine.\nThe scenario has been tested using VirtualBox and Lima (for MacBooks running Apple Silicon).\nWhile this tutorial may work with Ubuntu running on a cloud provider or another virtualization platform, it has not been tested.\nVirtualBox setup The following steps will set up a VirtualBox virtual machine running Ubuntu 24.04.\nInstall VirtualBox and Vagrant according to the instructions appropriate for your local system.\nIssue the following commands from the command line to create an Ubuntu 24.04 virtual machine.\nvagrant init bento/ubuntu-24.04 vagrant up Log into the newly launched virtual machine and continue to the Install Falco section below (the default password is vagrant). vagrant ssh Lima setup for Apple silicon (M1/M2) This section explains how to create an Ubuntu 24.04 VM on Apple computers running M1 silicon (as opposed to Intel).\nIf you are unsure what processor your Apple machine is running, you can find out by clicking the Apple icon in the upper left and choosing \u0026quot;About this Mac\u0026quot;. The first item listed, Chip, tells you what silicon you're running on.\nInstall Homebrew according to the project's documentation.\nUse Homebrew to install Lima.\nbrew install lima Create an Ubuntu 24.04 VM with Lima. limactl start --name=falco-quickstart template://ubuntu-lts Shell into the Ubuntu VM, and once you're in the VM, continue to the Install Falco section. limactl shell falco-quickstart Install Falco Regardless of which setup you used above, this section will show you how to install Falco on a host system. You'll begin by updating the package repository. Next, you'll install the dialog package. Then you'll install Falco and ensure it's up and running.\nSet up the package repository Add the Falco repository key. curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \\ sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg Add the Falco repository. sudo bash -c \u0026#39;cat \u0026lt;\u0026lt; EOF \u0026gt; /etc/apt/sources.list.d/falcosecurity.list deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] https://download.falco.org/packages/deb stable main EOF\u0026#39; Read the repository contents. sudo apt-get update -y Install dialog Install dialog, which is used by the Falco installer. sudo apt-get install -y dialog Install Falco Install the latest Falco version. sudo apt-get install -y falco When prompted, choose the Modern eBPF option. This will enable the usage of the modern eBPF-based driver.\nWhen prompted, choose Yes. Although we won't use the functionality in this exercise, this option allows Falco to update its rules automatically.\nWait for the Falco installation to complete - this should only take a few minutes.\nVerify Falco is running Make sure the Falco service is running. sudo systemctl status falco-modern-bpf.service The output should be similar to the following:\n● falco-modern-bpf.service - Falco: Container Native Runtime Security with modern ebpf Loaded: loaded (/usr/lib/systemd/system/falco-modern-bpf.service; enabled; preset: enabled) Active: active (running) since Wed 2024-09-18 08:40:04 UTC; 11min ago Docs: https://falco.org/docs/ Main PID: 4751 (falco) Tasks: 7 (limit: 2275) Memory: 24.7M (peak: 37.1M) CPU: 3.913s CGroup: /system.slice/falco-modern-bpf.service └─4751 /usr/bin/falco -o engine.kind=modern_ebpf Sep 18 08:40:12 vagrant falco[4751]: /etc/falco/falco.yaml Sep 18 08:40:12 vagrant falco[4751]: System info: Linux version 6.8.0-31-generic (buildd@lcy02-amd64-080) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 Sep 18 08:40:12 vagrant falco[4751]: Loading rules from file /etc/falco/falco_rules.yaml Sep 18 08:40:12 vagrant falco[4751]: Loading rules from file /etc/falco/falco_rules.local.yaml Sep 18 08:40:12 vagrant falco[4751]: The chosen syscall buffer dimension is: 8388608 bytes (8 MBs) Sep 18 08:40:12 vagrant falco[4751]: Starting health webserver with threadiness 2, listening on 0.0.0.0:8765 Sep 18 08:40:12 vagrant falco[4751]: Loaded event sources: syscall Sep 18 08:40:12 vagrant falco[4751]: Enabled event sources: syscall Sep 18 08:40:12 vagrant falco[4751]: Opening \u0026#39;syscall\u0026#39; source with modern BPF probe. Sep 18 08:40:12 vagrant falco[4751]: One ring buffer every \u0026#39;2\u0026#39; CPUs. See Falco in action Generate a suspicious event There is a Falco rule that is designed to trigger whenever someone accesses a sensitive file (of which, /etc/shadow is one). Run the following command to trigger that rule. sudo cat /etc/shadow \u0026gt; /dev/null Examine Falco's output One of the endpoints that Falco can write output to is syslog. There are multiple ways to examine the system logs, but we have featured two for our exercise: using journalctl and simply using cat on the log file.\nUsing journalctl\nRun the following command to retrieve Falco messages that have been generated with a priority of warning: sudo journalctl _COMM=falco -p warning You should see output similar to the following:\n... Sep 18 12:50:52 vagrant falco[4751]: 11:48:24.195279773: Warning Sensitive file opened for reading by non-trusted program (file=/etc/shadow gparent=sudo ggparent=bash gggparent=sshd evt_type=openat user=root user_uid=0 user_loginuid=1000 process=cat proc_exepath=/usr/bin/cat parent=sudo command=cat /etc/shadow terminal=34818 container_id=host container_name=host) ... Using /var/log/syslog\nLog messages describing Falco's activity are logged to syslog. Run the following command to retrieve Falco logs: sudo grep Sensitive /var/log/syslog You should see output similar to the following:\n... 2024-09-18T12:50:52.164570+00:00 vagrant falco: 11:48:24.195279773: Warning Sensitive file opened for reading by non-trusted program (file=/etc/shadow gparent=sudo ggparent=bash gggparent=sshd evt_type=openat user=root user_uid=0 user_loginuid=1000 process=cat proc_exepath=/usr/bin/cat parent=sudo command=cat /etc/shadow terminal=34818 container_id=host container_name=host) Cleanup Remove the Lima virtual machine If you wish, remove the Lima virtual machine\nlimactl delete falco-quickstart --force Remove the Virtualbox virtual machine If you wish, remove the Virtualbox virtual machine\nvagrant destroy Be sure you are in same subdirectory as the Vagrantfile\n","summary":"","tags":null,"title":"Try Falco on Linux","url":"https://v0-43--falcosecurity.netlify.app/docs/getting-started/falco-linux-quickstart/"},{"category":"docs","content":"Plugin Registry The registry is a GitHub repository that provides metadata and information about all plugins recognized by The Falco Project. It includes plugins hosted within this repository as well as those located in other repositories. These plugins are developed for Falco and shared with the community.\nRegistering your plugin In this section, we’ll outline the key steps to get your plugin registered successfully.\nTo complete the registration process, you’ll need to:\nCreate a clear and well-structured README for your plugin. Fill in all the required fields in the plugins section of the registry.yaml file, like in the below example. plugins: source: - id: 2 source: aws_cloudtrail name: cloudtrail description: Reads Cloudtrail JSON logs from files/S3 and injects as events authors: The Falco Authors contact: https://falco.org/community url: https://github.com/falcosecurity/plugins/tree/master/plugins/cloudtrail license: Apache-2.0 License You're free to choose the open source license you want, you can check https://choosealicense.com/ for help. Most of the current plugins are under Apache License 2.0.\nID Every source plugin requires its own unique plugin event ID to interoperate with Falco and the other plugins. This ID is used in the following ways:\nIt is stored inside in-memory event objects and used to identify the associated plugin that injected the event. It is stored in capture files and used to recreate in-memory event objects when reading capture files. It must be unique to ensure that events written by a given plugin will be properly associated with that plugin (and its event sources, see below).\nName Each plugin in the registry must have its own name and can be different from event source, which can be shared across multiple plugins (e.g., for k8s audit logs, there might be several plugins but only one type of event source).\nThe name should match this regular expression ^[a-z]+[a-z0-9_]*$.\nFields The fields are used for conditions in rules. Describe the available fields of your plugin in the README.\nFor example:\nName Type Description docker.status string Status of the event docker.id string ID of the event docker.from string From of the event (deprecated) docker.type string Type of the event docker.action string Action of the event docker.stack.namespace string Stack Namespace Propose your Plugin Once you're ready, follow these steps to submit your plugin for registration:\nFork the falcosecurity/plugins repository. Update the registry.yaml file by adding your plugin to the plugins section. Make sure to follow our Contributing Guide, e.g. all commits must be signed-off. Submit a Pull Request (PR) to the falcosecurity/plugins repository. For more details, check out the plugin registration documentation.\n","summary":"","tags":null,"title":"How to register a plugin","url":"https://v0-43--falcosecurity.netlify.app/docs/developer-guide/plugins/how-to-register/"},{"category":"docs","content":"Action Items (TL;DR) Read Install and Operate Guides and review falco.yaml for necessary preconditions. Refer to the relevant debugging guide based on suspected missing fields. Acknowledge that certain missing fields or data in Falco are legitimate. Background Many of the Supported Output Fields are derived from multiple events and mechanisms. To provide a more concrete explanation, for each spawned process, Falco extracts and derives fields from the clone*/*fork/execve* syscalls. Falco generates a struct in userspace, stores the relevant information within this struct, and then adds it to the process cache table in memory. If a process makes additional system calls during its lifetime, such as opening a file, in a Falco rule, you typically also export process fields — assuming we haven't missed the spawned process event and the information is available. These details extend to various use cases, and, in essence, dropped events can lead to missing fields as well as race conditions.\nAs a result, Falco logs can never be perfect, and null values can occur. We are constantly aiming to improve the robustness in this regard. We encourage you to contribute to the project if you encounter such cases or have improvement ideas. Also be aware that, unfortunately, missing fields can have different natures. Sometimes the field may be an empty string, or the string \u0026lt;NA\u0026gt;, or, if numeric, the default numeric value. These inconsistencies may be more difficult to address, as many Falco rules rely on legacy declarations.\nFurthermore, sometimes Linux may not operate exactly as expected. One concrete example is that shell built-ins like echo do not cause a new spawned process, and the echo command does not get logged with Falco. Similarly, if a base64 encoded string gets interpreted during decoding, you do not have the original base64 blob in the command args unless the command was passed with the sh -c flag. Lastly, some fields only work for certain kernel versions or system configs (e.g. proc.is_exe_upper_layer requires a container overlayfs).\nMissing Container Images Check the basics:\nIs the container runtime socket correctly mounted? For Kubernetes, mount with the HOST_ROOT prefix: /host/run/k3s/containerd/containerd.sock. See deploy-kubernetes example template. Is a custom path specified for the container runtime socket in Kubernetes? If yes, use the -o container_engines.cri.sockets[]=\u0026lt;socket_path\u0026gt; command line option when running Falco. The default paths include: /run/containerd/containerd.sock, /run/k3s/containerd/containerd.sock, /run/crio/crio.sock. To expedite lookups, attempt to disable asynchronous CRI API calls by using the -o container_engines.cri.disable_async=true command line option when running Falco. Falco monitors both host and container processes. If the container.id is set to host, it indicates that the process is running on the host, and therefore, no container image is associated with it. The k8s.* fields are extracted from the container runtime socket simultaneously as we look up the container.* fields from the CRI API calls responses.\nUsing CRI with containerd When using containerd as your container runtime, you should configure Falco to use the CRI engine to consume the containerd socket (/run/containerd/containerd.sock). This is important because:\nThe native containerd protocol does not support container names - it only provides container IDs Containerd typically exposes two interfaces on the same socket: the native containerd protocol and the CRI (Container Runtime Interface) protocol The CRI protocol provides richer metadata, including container names If you are missing container.name or other container metadata fields while using containerd, ensure you are using the CRI engine configuration (not the containerd engine) in your Falco setup. For example, configure the container plugin with:\nengines: cri: enabled: true sockets: - /run/containerd/containerd.sock containerd: enabled: false Carefully read the field description documentation:\nSupported Output Fields container.* retrieved from the container runtime socket Supported Output Fields k8s.* also retrieved from the container runtime socket The container info enrichment, while robust, depends on the speed of making API requests against the container runtime socket.\nFalco's metrics config (see also Falco Metrics) provides a range of useful metrics related to software functioning, now also featuring metrics around Falco's internal state:\nstate_counters_enabled: true Here is an example metrics log snippet highlighting the fields crucial for this analysis.\n{ \u0026#34;output_fields\u0026#34;: { \u0026#34;evt.source\u0026#34;: \u0026#34;syscall\u0026#34;, \u0026#34;falco.n_containers\u0026#34;: 50, \u0026#34;falco.n_missing_container_images\u0026#34;: 0, }, \u0026#34;rule\u0026#34;: \u0026#34;Falco internal: metrics snapshot\u0026#34; } falco.n_containers indicates how many containers are running at a given time, typically less than 100-300 at maximum. falco.n_missing_container_images is an updated snapshot of how many containers are internally stored in Falco without a container image at any given time.\nTo complicate matters, some processes in Kubernetes run in the pod sandbox container, which has no container image in the API responses. In such cases, the container.id is the same as the k8s.pod.sandbox_id. If the container image is consistently missing throughout the lifetime of the container, it's likely a process in a pod sandbox container in the majority of the cases. However, sandbox containers likely constitute less than 1% of the distinct containers in your overall Falco logs. Note that this comparison will be fully supported by Falco 0.38 and is a work in progress.\nAdditionally, the improvement of the overall efficiency of the container engine, especially for the -o container_engines.cri.disable_async=true option, is also a work in progress. A more performant implementation is expected to be available by Falco 0.38. This improvement aims to address missing images observed by adopters and resolve most cases, leaving only some edge cases of race conditions where the lookup hasn't happened yet.\nMissing User Names Ensure proper mounts (e.g., /etc:/host/etc) when running Falco as a daemonset in Kubernetes, for example. If you expect Falco to be aware of Kubernetes Control Plane users, especially when execing into a pod (kubectl exec), we must disappoint you. The Linux kernel lacks knowledge of the control plane. However, we are actively exploring ways to support this. Refer to this issue for more details. Missing Process Tree Fields Let's consider another example: the fields related to the process tree lineage (e.g. proc.aname*).\nFalco adds processes to a cache in userspace when a new process starts and removes them when the process exits. The goal is to maintain a current view of running processes on the Linux host at any time. However, this also means that there are cases where the parent legitimately exits, re-parenting occurs, and/or PIDs get replaced or re-used. As a result, missing processes in the process ancestry (process tree) may be due to dropped or missed events, failure to store the event, or the process exiting without proper tracking of re-parenting or orphan process cases by Falco. Furthermore, a history of all spawned_process events is not equivalent to the current process tree on the system. Check out the Falco rules macro container_entrypoint for one such example and explore this resource. In summary, Falco aims to closely preserve the true system state, similar to the Linux kernel itself. Falco's metrics config (see also Falco Metrics) provides a range of useful metrics related to software functioning, now also featuring metrics around Falco's internal state:\nstate_counters_enabled: true Here is an example metrics log snippet highlighting the fields crucial for this analysis.\n{ \u0026#34;output_fields\u0026#34;: { \u0026#34;evt.source\u0026#34;: \u0026#34;syscall\u0026#34;, \u0026#34;falco.n_drops_full_threadtable\u0026#34;: 0, \u0026#34;falco.n_store_evts_drops\u0026#34;: 0, \u0026#34;falco.n_failed_fd_lookups\u0026#34;: 0, \u0026#34;falco.n_failed_thread_lookups\u0026#34;: 0, \u0026#34;falco.n_retrieve_evts_drops\u0026#34;: 0 }, \u0026#34;rule\u0026#34;: \u0026#34;Falco internal: metrics snapshot\u0026#34; } falco.n_drops_full_threadtable and falco.n_store_evts_drops reflect similar occurrences. They are monotonic counters indicating how often a spawned process event was dropped due to a full table (configurable by Falco 0.38 with a higher default value) and how frequently store actions to update the process structs in memory failed and were subsequently dropped. On the flip side, there are also counters keeping track of failed lookup or retrieve actions. Internally, Falco is granular and talks about threads, not processes.\nReferences and Community Discussions [TRACKING] Re-audit container engines for empty container info values (Initial focus on CRI for Kubernetes) [PROPOSAL] Inject Kubernetes Control Plane users into Falco syscalls logs for kubectl exec activities ","summary":"","tags":null,"title":"Missing Fields in Falco Logs","url":"https://v0-43--falcosecurity.netlify.app/docs/troubleshooting/missing-fields/"},{"category":"docs","content":" Falco consumes streams of events and evaluates them against a set of security rules to detect abnormal behavior. By default, Falco is pre-configured to consume events from the Linux Kernel. This scenario requires Falco to be privileged, and depending on the kernel version installed on the host, a driver needs to be installed.\nFor other installation scenarios, such as consuming cloud events or other data sources using plugins, please refer to the Plugins section.\nThere are two main methods to install Falco on your host using the released Falco packages:\nRPM or DEB package (includes Systemd setup): This method is detailed on this page. Tarball archive: For instructions, refer to the Install on a host (tarball) page. System requirements Falco runs on Linux and is available for the x86_64 and aarch64 architectures. Falco with its bundled plugins requires GLIBC 2.28 or newer. You can check your system's GLIBC version by running ldd --version.\nInstall This installation method is for Linux distributions with a package manager that supports DEB (Debian, Ubuntu) or RPM (CentOS, RHEL, Fedora, Amazon Linux) packages.\nIn interactive installations, the Falco installation package uses the dialog binary for configuration prompts. The dialog allows the user to complete the Systemd setup which includes:\nThe driver selection (kmod, ebpf, modern_ebpf) or automatic selection The Falcoctl service setup In non-interactive installations (e.g., dialog is not available, or if the user disables it by setting FALCO_FRONTEND=noninteractive when installing Falco using the package manager), the automatic driver selection is enabled by default and for other options, the user needs to manually configure the Systemd services.\nEnv variables The following environment variables can be used to customize the installation process:\nFALCO_FRONTEND: Set to noninteractive to disable the dialog prompts. The default is dialog. FALCO_DRIVER_CHOICE: Set to kmod, ebpf, or modern_ebpf to choose a driver; set to none to disable service installation. If one of the previous option is selected, the dialog will be skipped too. The default (empty) is automatic selection. FALCOCTL_ENABLED: Set to no to disable the automatic rules update provided by falcoctl. The default (empty) or any value other than no will keep the option enabled. These environment variables can be used in conjunction with the package manager (as described in the following sections) to customize the installation process as needed.\nExamples:\nNo dialog, no driver, no automatic rules update:\nFALCO_DRIVER_CHOICE=none apt-get install -y falco Install with kmod driver and automatic rules update:\nFALCO_DRIVER_CHOICE=kmod apt-get install -y falco No dialog, automatic selection and automatic rules update:\nFALCO_FRONTEND=noninteractive apt-get install -y falco No dialog, automatic selection and no automatic rules update:\nFALCO_FRONTEND=noninteractive FALCOCTL_ENABLED=no apt-get install -y falco apt (Debian/Ubuntu) The following steps are for Debian and Debian-based distributions, such as Ubuntu, which use the apt package manager.\nTrust the falcosecurity GPG key\ncurl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \\ sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg Configure the apt repository\necho \u0026#34;deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] https://download.falco.org/packages/deb stable main\u0026#34; | \\ sudo tee -a /etc/apt/sources.list.d/falcosecurity.list In older releases of Debian (Debian 9 and older ones), you might need to additionally install the package apt-transport-https to allow access to the Falco repository using the https protocol.\nThe following command will install that package on your system:\nsudo apt-get install apt-transport-https Update the package list\nsudo apt-get update -y Install some required dependencies that are needed to build the Kernel Module and the eBPF probe\nNote: You don't need to install these dependencies if you want to use the Modern eBPF.\nsudo apt install -y dkms make linux-headers-$(uname -r) # If you use falcoctl driver loader to build the eBPF probe locally you need also clang toolchain sudo apt install -y clang llvm # You can install also the dialog package if you want it sudo apt install -y dialog Install the Falco package\nsudo apt-get install -y falco yum (CentOS/RHEL/Fedora/Amazon Linux) Trust the falcosecurity GPG key\nsudo rpm --import https://falco.org/repo/falcosecurity-packages.asc Configure the yum repository\nsudo curl -o /etc/yum.repos.d/falcosecurity.repo https://falco.org/repo/falcosecurity-rpm.repo Update the package list\nsudo yum update -y Install some required dependencies that are needed to build the Kernel Module and the eBPF probe\nNote: You don't need to install these dependencies if you want to use the Modern eBPF.\n# If necessary install it using: `yum install epel-release` (or `amazon-linux-extras install epel` in case of amzn2), then `yum install make dkms`. sudo yum install -y dkms make # If the package was not found by the below command, you might need to run `yum distro-sync` in order to fix it. Rebooting the system may be required. sudo yum install -y kernel-devel-$(uname -r) # If you use falcoctl driver loader to build the eBPF probe locally you need also clang toolchain sudo yum install -y clang llvm # You can install also the dialog package if you want it sudo yum install -y dialog Install the Falco package\nsudo yum install -y falco You might need to validate the driver signature if your system has UEFI SecureBoot enabled. Follow these steps to do so:\nImport the DKMS Machine Owner Key\n```shell sudo mokutil --import /var/lib/dkms/mok.pub ``` Restart the system and wait for the MOK key enrollment prompt\nChoose the option: Enroll MOK\nLoad the Falco driver\n```shell sudo insmod /var/lib/dkms/falco/\u0026lt;driver-version\u0026gt;/$(uname -r)/x86_64/module/falco.ko.xz ``` RHEL 8 / UBI 8 users: Starting from Falco 0.42, you may need to set the LD_PRELOAD environment variable due to a glibc compatibility issue:\nLD_PRELOAD=/lib64/libresolv.so.2 falco When using systemd, you can add this to your service override or edit the unit file to include Environment=\u0026quot;LD_PRELOAD=/lib64/libresolv.so.2\u0026quot;.\nzypper (openSUSE) Trust the falcosecurity GPG key\nsudo rpm --import https://falco.org/repo/falcosecurity-packages.asc Configure the zypper repository\nsudo curl -o /etc/zypp/repos.d/falcosecurity.repo https://falco.org/repo/falcosecurity-rpm.repo Update the package list\nsudo zypper -n update Install some required dependencies that are needed to build the Kernel Module and the eBPF probe\nNote: You don't need to install these dependencies if you want to use the Modern eBPF.\nsudo zypper -n install dkms make # If the package was not found by the below command, you might need to run `zypper -n dist-upgrade` in order to fix it. Rebooting the system may be required. sudo zypper -n install kernel-default-devel-$(uname -r | sed s/\\-default//g) # If you use falcoctl driver loader to build the eBPF probe locally you need also clang toolchain sudo zypper -n install clang llvm # You can install also the dialog package if you want it sudo zypper -n install dialog Install Falco:\nsudo zypper -n install falco Uninstall Falco:\nsudo zypper rm falco Systemd setup Setup with dialog By default, if you have the dialog binary installed on your system, you will be prompted with this:\nFrom here you can choose one of our 3 drivers Kmod, eBPF, Modern eBPF, a Manual configuration or the Automatic selection (recommended) to trigger the automatic logic to select the best driver for you. When you choose a driver from the dialog, the systemd service is always enabled by default so it will start at every system reboot. If you want to disable this behavior type systemctl disable falco-kmod.service (if you are using the kernel module like in this example).\nAfter the first dialog, you should see a second one:\nIf you choose Yes, falcoctl will periodically check for ruleset updates and, if a new update is available, will pull and install it.\nManual configuration If you chose Manual configuration from the dialog, you need to complete the setup configuration.\nFirst, let's verify the available services:\n$ sudo systemctl list-unit-files \u0026#34;falco*\u0026#34; UNIT FILE STATE PRESET falco-bpf.service disabled enabled falco-custom.service disabled enabled falco-kmod-inject.service static enabled falco-kmod.service disabled enabled falco-modern-bpf.service disabled enabled falcoctl-artifact-follow.service disabled enabled Using the systemctl command, you can now enable the desired unit to start at boot time.\nLet's say you want to enable the modern eBPF probe:\n$ sudo systemctl enable falco-modern-bpf.service Created symlink /etc/systemd/system/falco.service → /usr/lib/systemd/system/falco-modern-bpf.service. Created symlink /etc/systemd/system/multi-user.target.wants/falco-modern-bpf.service → /usr/lib/systemd/system/falco-modern-bpf.service. $ sudo systemctl list-unit-files \u0026#34;falco*\u0026#34; UNIT FILE STATE PRESET falco-bpf.service disabled enabled falco-custom.service disabled enabled falco-kmod-inject.service static - falco-kmod.service disabled enabled falco-modern-bpf.service enabled enabled falco.service alias - falcoctl-artifact-follow.service disabled enabled Or you'd like to switch to using the kernel module:\n$ sudo systemctl disable falco-modern-bpf.service Removed \u0026#34;/etc/systemd/system/multi-user.target.wants/falco-modern-bpf.service\u0026#34;. Removed \u0026#34;/etc/systemd/system/falco.service\u0026#34;. $ sudo systemctl enable falco-kmod.service Created symlink /etc/systemd/system/falco.service → /usr/lib/systemd/system/falco-kmod.service. Created symlink /etc/systemd/system/multi-user.target.wants/falco-kmod.service → /usr/lib/systemd/system/falco-kmod.service. $ sudo systemctl list-unit-files \u0026#34;falco*\u0026#34; UNIT FILE STATE PRESET falco-bpf.service disabled enabled falco-custom.service disabled enabled falco-kmod-inject.service static - falco-kmod.service enabled enabled falco-modern-bpf.service disabled enabled falco.service alias - falcoctl-artifact-follow.service disabled enabled 7 unit files listed. As you can see, enabling the falco-kmod.service, falco-modern-bpf.service or falco-custom.service also creates a new alias/service called falco.service that can be used in place of the aliased ones.\nAs a side note, if you prefer not to use the falcoctl tool to automatically update your rules, you can mask it as follows. Otherwise, as explained here, Falco will enable it too.\n$ sudo systemctl mask falcoctl-artifact-follow.service Created symlink /etc/systemd/system/falcoctl-artifact-follow.service → /dev/null. Configuring services If you installed the Falco packages using the dialog option, all your services should already be up and running. However, if you chose the Manual configuration option, you need to configure the services manually.\nIf you need to switch from one service to another, ensure that the current service is properly stopped before starting the new one. This can be done by using the appropriate service management commands for your system (e.g., systemctl stop \u0026lt;service_name\u0026gt; and systemctl start \u0026lt;new_service_name\u0026gt;).\nFor example, if you want to use the service for the eBPF probe:\nType systemctl list-units | grep falco to check that no unit is running. Stop the current services, if any.\nNow you have to decide whether you want the Falcoctl service running together with the Falco one. If yes you don't have to do anything, else you will need to mask the Falcoctl service with systemctl mask falcoctl-artifact-follow.service. The Falcoctl service is strictly related to the Falco one so if you don't mask it, it will be started together with the Falco service.\nType falcoctl driver config --type ebpf to configure Falco to use eBPF probe, then falcoctl driver install to download/compile the eBPF probe.\nNow running systemctl start falco-bpf.service and typing systemctl list-units | grep falco you should see something like that (supposing you didn't mask the Falcoctl service):\nfalco-bpf.service loaded active running Falco: Container Native Runtime Security with ebpf falcoctl-artifact-follow.service loaded active running Falcoctl Artifact Follow: automatic artifacts update service If you want to stop both services in one shot\nsystemctl stop falco-bpf.service Falcoctl service (automatic rules update) If this service is enabled (as default), typing systemctl list-units | grep falco you should see something similar to this:\nfalco-kmod-inject.service loaded active exited Falco: Container Native Runtime Security with kmod, inject. falco-kmod.service loaded active running Falco: Container Native Runtime Security with kmod falcoctl-artifact-follow.service loaded active running Falcoctl Artifact Follow: automatic artifacts update service falco-kmod-inject.service injects the kernel module and exits. This unit remains after exit to detach the kernel module when the falco-kmod.service will be stopped. falco-kmod.service instance of Falco running the kernel module. falcoctl-artifact-follow.service instance of Falcoctl that searches for new rulesets. This unit will be stopped when falco-kmod.service terminates. The Falcoctl service is strictly related to the Falco one:\nwhen the Falco service starts it searches for a unit called falcoctl-artifact-follow.service and if present it starts it. Please note that following this pattern, if you enable the Falco service and you reboot your system, Falcoctl will start again with Falco even if you don't enable it through systemd enable! You can disable this behavior by stopping the Falcoctl service and masking it systemctl mask falcoctl-artifact-follow.service. when the Falco service stops also the Falcoctl service is stopped. In case the Falcoctl service is not enabled, the Falco package will only start the falco-kmod.service. Typing systemctl list-units | grep falco you should see something similar to this:\nfalco-kmod-inject.service loaded active exited Falco: Container Native Runtime Security with kmod, inject. falco-kmod.service loaded active running Falco: Container Native Runtime Security with kmod In this mode, the Falcoctl service is masked by default so if you want to enable it in a second step you need to type systemctl unmask falcoctl-artifact-follow.service.\nCustom service You may have noticed a Falco unit called falco-custom.service. You should use it when you want to run Falco with a custom configuration like a plugin. Please note that in this case you have to modify this template according to how you want to run Falco, the unit should not be used as is!\nConfiguration The Falco configuration file is located at /etc/falco/falco.yaml. You can edit it to customize Falco's behavior.\nSince Falco 0.38.0, a new config key, config_files, allows the user to load additional configuration files to override main config entries. This allows user to keep local customization between Falco upgrades. Its default value points to a new folder, /etc/falco/config.d/ that gets installed by Falco and will be processed to look for local configuration files.\nHot Reload By default, with the watch_config_files configuration option enabled, Falco automatically monitors changes to configuration and rule files. When these files are modified, Falco will automatically reload the updated configuration without requiring a restart.\nIf this option is disabled, you can manually restart the Falco systemd service to apply the changes:\nsystemctl restart falco Upgrade apt (Debian/Ubuntu) If you configured the apt repository by having followed the instructions for Falco 0.27.0 or older, you may need to update the repository URL, otherwise, feel free to ignore this message\nsed -i \u0026#39;s,https://dl.bintray.com/falcosecurity/deb,https://download.falco.org/packages/deb,\u0026#39; /etc/apt/sources.list.d/falcosecurity.list apt-get clean apt-get -y update Check in the apt-get update log that https://download.falco.org/packages/deb is present.\nIf you installed Falco by following the provided instructions:\napt-get --only-upgrade install falco yum (CentOS/RHEL/Fedora/Amazon Linux) If you configured the yum repository by having followed the instructions for Falco 0.27.0 or older, you may need to update the repository URL, otherwise, feel free to ignore this message\nsudo sed -i \u0026#39;s,https://dl.bintray.com/falcosecurity/rpm,https://download.falco.org/packages/rpm,\u0026#39; /etc/yum.repos.d/falcosecurity.repo sudo yum clean all Then check that the falcosecurity-rpm repository is pointing to https://download.falco.org/packages/rpm/:\nsudo sudo yum repolist -v falcosecurity-rpm If you installed Falco by following the provided instructions:\nCheck for updates:\nsudo yum check-update If a newer Falco version is available:\nsudo yum update falco zypper (openSUSE) If you configured the zypper repository by having followed the instructions for Falco 0.27.0 or older, you may need to update the repository URL, otherwise, feel free to ignore this message\nsudo sed -i \u0026#39;s,https://dl.bintray.com/falcosecurity/rpm,https://download.falco.org/packages/rpm,\u0026#39; /etc/zypp/repos.d/falcosecurity.repo sudo zypper refresh Then check that the falcosecurity-rpm repository is pointing to https://download.falco.org/packages/rpm/:\nsudo zypper lr falcosecurity-rpm If you installed Falco by following the provided instructions:\nsudo zypper update falco Kernel Upgrades When performing kernel upgrades on your host, a reboot is required. When using a eBPF probe or a Kernel Module driver, the Falco driver loader (i.e., falcoctl driver) should be able to automatically find a pre-built driver (or build it on the fly) corresponding to the updated kernel release (uname -r), making it easy to handle kernel upgrades. The Falco Project features a kernel crawler and automated CI, ensuring you can always obtain the necessary pre-built driver artifact, even for the latest kernel releases we support.\nUninstall apt (Debian/Ubuntu) sudo apt-get --purge autoremove falco yum (CentOS/RHEL/Fedora/Amazon Linux) sudo yum remove falco zypper (openSUSE) sudo zypper remove falco Package signing On December, 2025 we started rotating the GPG key used to sign Falco packages. Check out the related blog post and make sure you're using the most up-to-date key available at falco.org/repo/falcosecurity-packages.asc.\nMost Falco packages available at download.falco.org are provided with a detached signature that can be used to verify that the package information downloaded from the remote repository can be trusted.\nThe latest trusted public GPG key used for packages signing can be downloaded from falco.org/repo/falcosecurity-packages.asc. The following table lists all the keys employed by the organization currently and in the past, including the revoked ones. We recommend updating the revoked keys to download their revocation certificate, and eventually removing them from your package verification system due to the signature made with them not being trustable anymore.\nFingerprint Expiration Usage Status Download 478B2FBBC75F4237B731DA4365106822B35B1B1F 2028-12-10 Signing Falco Packages Trusted falcosecurity-B35B1B1F.asc 2005399002D5E8FF59F28CE64021833E14CB7A8D 2026-01-17 Signing Falco Packages Revoked falcosecurity-14CB7A8D.asc 15ED05F191E40D74BA47109F9F76B25B3672BA8F 2023-02-24 Signing Falco Packages Revoked falcosecurity-3672BA8F.asc Troubleshooting This section aims to offer further guidance when something doesn't go as expected in the installation of Falco.\nUnable to find a prebuilt driver ERROR failed: unable to find a prebuilt driver This error message appears when the falcoctl driver loader tool, which looks for the Falco driver and loads it in memory, is not able to find a pre-built driver, neither as an eBPF probe nor as a kernel module, at the [Falco driver repository] (https://download.falco.org).\nYou can easily browse and search the supported targets at download.falco.org/driver/site.\nThis means that there's no prebuilt driver available for the kernel running on the machine where Falco is going to be installed.\nHowever, you can add your kernel release version to the build grid the pipeline refers to building the drivers. Follow this tutorial to contribute the required configuration.\nThere are a limited set of Linux distributions whose kernels are supported by the current prebuilt driver distribution pipeline.\ndriverkit is the tool used to build those drivers. Hence, it needs to support the specific Linux distribution. Find whether your Linux distribution is supported here.\nEnable the BPF JIT Compiler If you are using the eBPF probe, in order to ensure that performance is not degraded, make sure that:\nYour kernel has CONFIG_BPF_JIT enabled net.core.bpf_jit_enable is set to 1 (enable the BPF JIT Compiler) This can be verified via sysctl -n net.core.bpf_jit_enable.\n","summary":"","tags":null,"title":"Install on a host (DEB, RPM)","url":"https://v0-43--falcosecurity.netlify.app/docs/setup/packages/"},{"category":"docs","content":"Introduction The Go SDK provides prebuilt constructs and definitions that help developing plugins by abstracting all the complexities related to the bridging between the C and the Go runtimes. The Go SDK takes care of satisfying all the plugin framework requirements without having to deal with the low-level details, by also optimizing the most critical code paths.\nThe SDK allows developers to choose either from a low-level set of abstractions, or from a more high-level set of packages designed for simplicity and ease of use. The best way to approach the Go SDK is to start by importing a few high-level packages, which is enough to satisfy the majority of use cases.\nThis section documents the Go SDK at a high-level, please refer to the official Go SDK documentation for deeper details.\nArchitecture of the Go SDK Since Falcosecurity plugins run in a C runtime, the Go SDK has been designed to abstract most of the complexity related to writing C-compliant code acceptable by the plugin framework, so that developers can focus on writing Go code only.\nAt a high level, the SDK is on top of three fundamental packages with different levels of abstractions:\nPackage sdk is a container for all the basic types, definitions, and helpers that are reused across all the SDK parts.\nPackage sdk/symbols contains prebuilt implementations for all the C symbols that plugins must export to be accepted by the framework. The prebuilt C symbols are divided in many subpackages, so that each of them can be imported individually to opt-in/opt-out each symbol.\nPackage sdk/plugins provide high-level definition and base types for implementing plugin capabilities. This uses sdk/symbols internally and takes care of importing all the prebuilt C symbols required each plugin capability respectively. This is the main entrypoint for developers to write plugins in Go.\nTwo additional packages ptr and cgo are used internally to simplify and optimize the state management and the usage of C-allocated memory pointers.\nFor some use cases, developers can consider using the SDK layers selectively. This is meaningful only if developers wish to manually write part of the low-level C details of the framework in their plugins, but still want to use some parts of the SDK. However, this is discouraged if not for advanced use cases only. Developers are encouraged to use the sdk/plugins to build Falcosecurity plugins, which is easier to use and will have less frequent breaking changes.\nFurther details can be found in the documentation of each package: sdk, sdk/symbols, and sdk/plugins.\nGetting Started The SDK is built on top of a set of minimal composable interfaces describing the behavior of plugins and plugin instances. As such, developing plugins is as easy as defining a struct type representing the plugin itself, ensuring that the mandatory interface methods are defined on it, and then registering it to the SDK.\nTo use the Go SDK, all you need to import are the sdk and sdk/plugins packages. The first contains all the core types and definitions used across the rest of the SDK packages, whereas the latter contains built-in constructs to develop plugins. The subpackages sdk/plugins/source and sdk/plugins/extractor contain specialized definitions for the event sourcing and the field extraction capabilities respectively.\nThe dummy plugin, documented in the next sections, is a simple example that helps understand how to start writing Go plugins with this SDK. The SDK also provides a set of base examples to get you started with plugin development.\nDefining a Plugin with Field Extraction Capability In the Go SDK, a plugin with field extraction capability is a type implementing the following interface:\n// sdk/plugins/extractor type Plugin interface { ... Info() *sdk.Info Init(config string) error Fields() []sdk.FieldEntry Extract(req sdk.ExtractRequest, evt sdk.EventReader) error } Info() returns all the info about the plugin. The returned plugins.Info struct should be filled in by the plugin author and contains fields such as the plugin ID, name, description, etc.\nInit() method is called to initialize a plugin when the framework allocates it. A user-defined configuration string is passed by the framework. This is where the plugin can initialize its internal state and acquire all the resources it needs.\nFields() returns an array of sdk.FieldEntry representing all the fields supported by a plugin for extraction. The order of the fields is relevant, as their index is used as an identifier during extraction.\nExtract() extracts the value of one of the supported fields from a given event passed in by the framework. The sdk.ExtractRequest argument should be used to set the extracted value.\nOptional Interfaces type Destroyer interface { Destroy() } type InitSchema interface { InitSchema() *SchemaInfo } Plugins with field extraction capability can optionally implement the sdk.Destroyer interface. In that case, Destroy() will be called when the plugin gets destroyed and can be used to release any allocated resource. they can also also optionally implement the sdk.InitSchema interface. In that case, InitSchema() will be used to to return a schema describing the data expected to be passed as a configuration during the plugin initialization. This follows the semantics documented for get_init_schema. Currently, the schema must follow the JSON Schema specific, which in Go can also be easily auto-generated with external packages (e.g. alecthomas/jsonschema).\nDefining a Plugin with Event Sourcing Capability In the Go SDK, a plugin with event sourcing capability must specify two types, one of the plugin itself and one for the plugin instances, implementing the following interfaces respectively:\n// sdk/plugins/source type Plugin interface { ... Info() *sdk.Info Init(config string) error Open(params string) (Instance, error) } // sdk/plugins/source type Instance interface { ... NextBatch(pState PluginState, evts EventWriters) (int, error) } The source.Plugin interface has many functions in common with extractor.Plugin.\nOpen() creates a new plugin instance to open a new stream of events. The framework provides the user-defined open parameters to customize the event source. The return value must implement the source.Instance interface, and its lifecycle ends when the event stream is closed.\nThe source.Instance interface represents plugin instances for an opened event stream, and has one mandatory method and a few optional ones.\nNextBatch creates a new batch of events to be pushed in the event stream. The SDK provides a pre-allocated batch to write events into, in order to manage the used memory optimally.\nOptional Interfaces type Destroyer interface { Destroy() } type Closer interface { Close() } type InitSchema interface { InitSchema() *SchemaInfo } type OpenParams interface { OpenParams() ([]OpenParam, error) } type Progresser interface { Progress(pState sdk.PluginState) (float64, string) } type Stringer interface { String(evt sdk.EventReader) (string, error) } Plugins with event sourcing capabilities can optionally implement the sdk.Destroyer and sdk.InitSchema interfaces, just like mentioned in the section above.\nAdditionally, they can also implement the sdk.OpenParams interface. If requested by the application, the framework may call OpenParams() before opening the event stream to obtains some suggested values that would valid parameters for Open(). For more details, see the documentation of list_open_params.\nPlugin instances can optionally implement the sdk.Closer, sdk.Progresser, and sdk.Stringer interfaces. If sdk.Closer is implemented, the Close() method is called while closing the event stream and can be used to release the resources used by the plugin instance. If sdk.Progresser is implemented, the Progress() method is called by the SDK when the framework requests progress data about the event stream of the plugin instance. Progress() must return a float64 with a value between 0 and 1 representing the current progress percentage, and a string representation of the same progress value. If sdk.Stringer is implemented, the String() method must return a string representation of an event created by the plugin, which is used by the framework as an extraction value of the evt.plugininfo field. The string representation should be on a single line and contain important information about the event.\nBest Practices and Go SDK Prebuilts for Source Instances Although the Go SDK gives developers high control and flexibility, in the general case implementing the sdk.NextBatcher interface is not trivial. Custom definitions of source.Instance require developers to be mindful of the following while implementing the NextBatch() function:\nIt should return as fast as possible and should try to fill-up event batch up to its maximum capacity Listen for a timeout of few milliseconds and return the batch in its current state once the timeout is expired Conceive the case in which Close() is called before NextBatch() has returned. This can potentially happen if the plugin framework receives signals such as SIGINT or SIGTERM Minimize the number of memory allocations Keep returning sdk.ErrEOF after returning it the first time Considering the above, the SDK provides prebuilt implementations of source.Instance that satisfy a broad range of use cases, so that developers need to define their own type only if they have advanced or custom requirements.\n// sdk/plugins/source func NewPullInstance(pull source.PullFunc, options ...func(*\u0026lt;unexported-type\u0026gt;)) (source.Instance, error) func NewPushInstance(evtC \u0026lt;-chan source.PushEvent, options ...func(*\u0026lt;unexported-type\u0026gt;)) (source.Instance, error) source.NewPullInstance and source.NewPushInstance are two constructors for SDK-provided source.Instance implementations that cover the following use cases:\nPull Model: for when the event source can be implemented sequentially and the time required to generate a sequence of event is deterministic. This is implemented with a functional design, where the passed-in callback is expected to be non-suspensive and to return quickly Push Model: for when the event source can be suspensive and there is no time guarantee regarding when an event gets produced. For instance, this applies for all event sources that generate events from webhook events. Given the event-driven nature of this use case, this is implemented by passing event data in the form of byte slices through a channel The prebuilt source.Instances can be configured in the function constructors by using the Go options pattern. The SDK provides options for configuring and overriding all the default values:\n// sdk/plugins/source func WithInstanceContext(ctx context.Context) func(*\u0026lt;unexported-type\u0026gt;) func WithInstanceTimeout(timeout time.Duration) func(*\u0026lt;unexported-type\u0026gt;) func WithInstanceClose(close func()) func(*\u0026lt;unexported-type\u0026gt;) func WithInstanceBatchSize(size uint32) func(*\u0026lt;unexported-type\u0026gt;) func WithInstanceEventSize(size uint32) func(*\u0026lt;unexported-type\u0026gt;) func WithInstanceProgress(progress func() (float64, string)) func(*\u0026lt;unexported-type\u0026gt;) Here's an example of how the Pull Model prebuilt can be used to implement an event source:\nfunc (m *MyPlugin) Open(params string) (source.Instance, error) { counter := uint64(0) pull := func(ctx context.Context, evt sdk.EventWriter) error { counter++ if err := gob.NewEncoder(evt.Writer()).Encode(counter); err != nil { return err } evt.SetTimestamp(uint64(time.Now().UnixNano())) return nil } return source.NewPullInstance(pull) } Registering a Plugin in the SDK After defining proper types for the plugin, the only thing remaining is to register it in the SDK so that it can be used in the plugin framework.\n// sdk/plugins type FactoryFunc func() plugins.Plugin // sdk/plugins func SetFactory(plugins.FactoryFunc) // sdk/plugins/extractor func Register(extractor.Plugin) // sdk/plugins/source func Register(source.Plugin) The newly created plugin type need to be registered to the SDK in a Go init function and through the plugins.SetFactory() function. plugins.FactoryFunc is a function type that is used by the SDK to create plugins when requested by the plugin framework. Then, the source.Register() and extractor.Register() functions should be invoked inside the body of plugins.FactoryFunc functions to implement the event sourcing and the field extraction capabilities respectively.\nThe defined plugin types are expected to implement a given set of methods. Compilation will fail at the Register() functions if any of the required methods is not defined. Developers are encouraged to compose their structs with plugins.BasePlugin, and source.BaseInstance, which provide prebuilt boilerplate for many of those methods. In this way, developers just need to focus on implementing the few plugin-specific methods remaining.\nBesides the interface requirements, the defined types can contain arbitrary fields and methods. State variable that must be maintained during the plugin lifecycle (or in the lifecycle of an opened event stream) must be contained in the defined types. In this way, the SDK can guarantee that the state variables are not disposed by the garbage collector.\nInteracting with Events Generating new events, and extracting field values from them, are the hottest path in the plugin framework and can happen at a very high rate. For this reason, the Go SDK optimizes the memory usage as much as possible, avoiding reallocations and copies wherever possible. Internally, this sometimes means reading and writing on C-allocated memory from Go code directly, which is efficient but also very unsafe and can lead to unstable code.\nAs such, the SDK provides the two sdk.EventReader and sdk.EventWriter interfaces, which enable developers to safely read and write from events while still fully leveraging the underlying memory optimizations. sdk.EventReader gives a read-only view of an event, with accessor methods for all the internal fields, and sdk.EventWriter does the same in read-only mode.\ntype EventReader interface { EventNum() uint64 Timestamp() uint64 Reader() io.ReadSeeker } type EventWriter interface { SetTimestamp(value uint64) Writer() io.Writer } Event data can either be read or written through the standard io.SeekReader and io.Writer interfaces, returned by the Reader() and Writer() methods respectively. The SDK hides behind these interfaces all the safety and optimization mechanisms.\nFor plugins with event sourcing capability, a reusable batch of sdk.EventWriters is automatically allocated in each plugin source instance after the Open() method returns. This slab-allocator creates reusable event data by using the default sdk.DefaultBatchSize and sdk.DefaultEvtSize constants. Developers can override the automatic allocation to define batches of arbitrary sizes in the Open() method, by calling the SetEvents() method on the newly opened plugin instance before returning it. The reusable event batch can be created with the sdk.NewEventWriters function, that takes the event data size and batch size as arguments.\nfunc NewEventWriters(size, dataSize int64) (EventWriters, error) Note that the size of the reusable event batch defines the maximum size of each event batch created by the plugin in NextBatch.\nCompiling Plugins After successfully writing a plugin, all you need is to compile it. Go allows compiling binaries as a C-compliant shared library with the -buildmode=c-shared flag. The build command will be something looking like:\ngo build -buildmode=c-shared -o \u0026lt;outname\u0026gt;.so *.go The SDK takes care of generating all the required C exported functions that the plugin framework needs to load the plugin. Once built, your plugin is ready to be used in the Falcosecurity plugin system.\nExample Go Plugin: dummy This section walks through the implementation of the dummy. This plugin returns events that are just a number value that increases with each event generated. Each increase is 1 plus a random \u0026quot;jitter\u0026quot; value that ranges from [0:jitter]. The jitter value is provided as configuration to the plugin in plugin_init. The starting value and the maximum number of events are provided as open parameters to the plugin in plugin_open.\nThis will show how the above API functions are actually used in a functional plugin. The source code for this plugin can be found at dummy.go.\nInitial Imports package main import ( ... \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/extractor\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/source\u0026#34; ) Importing the sdk and sdk/plugins packages is the first step for developing a Falcosecurity plugin in Go. The sdk package contains all the core types and definitions used across the other packages of the SDK. The sdk/plugins package contains prebuilt constructs for defining new plugins.\nThe sdk/plugins/source and sdk/plugins/extractor packages are required to register the event sourcing and field extraction capabilities. dummy implements both of them.\nThe Go module falcosecurity/plugin-sdk-go has its own documentation, which gives deeper insights about the internal architecture of the SDK.\nDefining the Plugin In the Go SDK, plugins are defined by a set of composable tiny interfaces. To define a new plugin, the first step is to define a new struct type representing the plugin itself, and then register it to the SDK. Plugins with event sourcing capability, like dummy, must define an additional type representing the opened instance of the plugin event stream.\ntype PluginConfig struct { // This reflects potential internal state for the plugin. In // this case, the plugin is configured with a jitter. Jitter uint64 `json:\u0026#34;jitter\u0026#34; jsonschema:\u0026#34;description=A random amount added to the sample of each event (Default: 10)\u0026#34;` } type Plugin struct { plugins.BasePlugin // Will be used to randomize samples rand *rand.Rand // Contains the init configuration values config PluginConfig } type PluginInstance struct { source.BaseInstance // Copy of the init params from plugin_open() initParams string // The number of events to return before EOF maxEvents uint64 // A count of events returned. Used to count against maxEvents. counter uint64 // A semi-random numeric value, derived from this value and // jitter. This is put in every event as the data property. sample uint64 } func init() { plugins.SetFactory(func() plugins.Plugin { p := \u0026amp;Plugin{} source.Register(p) extractor.Register(p) return p }) } Plugin Info An Info() method is needed to return a data struct containing all the plugin info. Info() is a required method for the defined plugin struct type. This plugin defined its info as a set of constants for simplicity, but it's not a requirement.\nconst ( PluginID uint32 = 3 PluginName = \u0026#34;dummy\u0026#34; PluginDescription = \u0026#34;Reference plugin for educational purposes\u0026#34; PluginContact = \u0026#34;github.com/falcosecurity/plugins\u0026#34; PluginVersion = \u0026#34;0.4.0\u0026#34; PluginEventSource = \u0026#34;dummy\u0026#34; ) ... func (m *Plugin) Info() *plugins.Info { return \u0026amp;plugins.Info{ ID: PluginID, Name: PluginName, Description: PluginDescription, Contact: PluginContact, Version: PluginVersion, RequiredAPIVersion: PluginRequiredApiVersion, EventSource: PluginEventSource, } } ... Initializing/Destroying the Plugin The mandatory Init() method serves as an initialization entrypoint for plugins. This is where the user-defined configuration string is passed in by the framework. The internal state of the plugin should be initialized at this level. An error can be returned to abort the plugin initialization.\nDefining the Destroy() method is optional but can be useful if some resource needs to be released before the plugin gets destroyed. The InitSchema() method is optional too, but it allows the framework to parse the init config automatically, thus avoiding the need of doing it manually inside Init().\n// Set the config default values. func (p *PluginConfig) setDefault() { p.Jitter = 10 } // This returns a schema representing the configuration expected by the // plugin to be passed to the Init() method. Defining InitSchema() allows // the framework to automatically validate the configuration, so that the // plugin can assume that it to be always be well-formed when passed to Init(). func (p *Plugin) InitSchema() *sdk.SchemaInfo { // We leverage the jsonschema package to autogenerate the // JSON Schema definition using reflection from our config struct. reflector := jsonschema.Reflector{ // all properties are optional by default RequiredFromJSONSchemaTags: true, // unrecognized properties don\u0026#39;t cause a parsing failures AllowAdditionalProperties: true, } if schema, err := reflector.Reflect(\u0026amp;PluginConfig{}).MarshalJSON(); err == nil { return \u0026amp;sdk.SchemaInfo{ Schema: string(schema), } } return nil } // Since this plugin defines the InitSchema() method, we can assume // that the configuration is pre-validated by the framework and // always well-formed according to the provided schema. func (m *Plugin) Init(cfg string) error { // initialize state m.rand = rand.New(rand.NewSource(time.Now().UnixNano())) // The format of cfg is a json object with a single param // \u0026#34;jitter\u0026#34;, e.g. {\u0026#34;jitter\u0026#34;: 10} // Empty configs are allowed, in which case the default is used. // Since we provide a schema through InitSchema(), the framework // guarantees that the config is always well-formed json. m.config.setDefault() json.Unmarshal([]byte(cfg), \u0026amp;m.config) return nil } func (m *Plugin) Destroy() { // nothing to do here } Opening/Closing a Stream of Events A plugin instance is created when the plugin event stream is opened, which can happen more than once during the plugin lifecycle. Plugins with event sourcing capability are required to define an Open() method that creates a returns a new plugin instance. This is where the framework passes in the user-defined open parameters string.\nThe plugin instance type returned by Open() can define an optional Close() method bundling any additional deinitialization logic to run while closing the event stream.\nfunc (m *Plugin) Open(prms string) (source.Instance, error) { // The format of params is a json object with two params: // - \u0026#34;start\u0026#34;, which denotes the initial value of sample // - \u0026#34;maxEvents\u0026#34;: which denotes the number of events to return before EOF. // Example: // {\u0026#34;start\u0026#34;: 1, \u0026#34;maxEvents\u0026#34;: 1000} var obj map[string]uint64 err := json.Unmarshal([]byte(prms), \u0026amp;obj) if err != nil { return nil, fmt.Errorf(\u0026#34;params %s could not be parsed: %v\u0026#34;, prms, err) } if _, ok := obj[\u0026#34;start\u0026#34;]; !ok { return nil, fmt.Errorf(\u0026#34;params %s did not contain start property\u0026#34;, prms) } if _, ok := obj[\u0026#34;maxEvents\u0026#34;]; !ok { return nil, fmt.Errorf(\u0026#34;params %s did not contain maxEvents property\u0026#34;, prms) } return \u0026amp;PluginInstance{ initParams: prms, maxEvents: obj[\u0026#34;maxEvents\u0026#34;], counter: 0, sample: obj[\u0026#34;start\u0026#34;], }, nil } func (m *PluginInstance) Close() { // nothing to do here } Returning new Events New events are generated in batch by the NextBatch function. The function is mandatory for plugins with event sourcing capability and must be defined as a method of the plugin instance struct type. The pState argument is the plugin struct type initialized in Init(), passed in by the framework for ease of access. The plugin state is passed as an instance of the sdk.PluginState interface, so a manual cast is required to access the internal state variables defined in the struct type.\nThe evts parameter is a sdk-managed batch of events to be used for creating new events. For that, the SDK uses a slab allocator and reuses the same event batch at every iteration to improve performance. The length of the evts list represents the maximum size of each event batch. Each element of the batch is an instance of sdk.EventWriter that provides handy methods to write the event info and data. Event data can be written with the Go io.Writer interface.\nIf an error is returned, the SDK returns a failure to the framework and invalidates the current batch. The special errors sdk.ErrTimeout and sdk.ErrEOF have a special meaning, and are used to either advise the framework that no new events are currently available, or that the event stream is terminated.\nfunc (m *PluginInstance) NextBatch(pState sdk.PluginState, evts sdk.EventWriters) (int, error) { // Return EOF if reached maxEvents if m.counter \u0026gt;= m.maxEvents { return 0, sdk.ErrEOF } // access the plugin state plugin := pState.(*Plugin) var n int var evt sdk.EventWriter for n = 0; m.counter \u0026lt; m.maxEvents \u0026amp;\u0026amp; n \u0026lt; evts.Len(); n++ { evt = evts.Get(n) m.counter++ // Increment sample by 1, also add a jitter of [0:jitter] m.sample += 1 + uint64(plugin.rand.Int63n(int64(plugin.config.Jitter+1))) // The representation of a dummy event is the sample as a string. str := strconv.Itoa(int(m.sample)) // It is not mandatory to set the Timestamp of the event (it // would be filled in by the framework if set to uint_max), // but it\u0026#39;s a good practice. evt.SetTimestamp(uint64(time.Now().UnixNano())) _, err := evt.Writer().Write([]byte(str)) if err != nil { return 0, err } } return n, nil } Printing Events As Strings Plugins with event sourcing capability can optionally have a String() method to format the contents of events created with a previous call to NextBatch(). The event data is readable through an instance of sdk.EventReader provided by the SDK. Internally, this allows safe memory access and an optimal reusage of the same buffer to maximize the performance of hot framework paths.\nfunc (m *Plugin) String(evt sdk.EventReader) (string, error) { evtBytes, err := ioutil.ReadAll(evt.Reader()) if err != nil { return \u0026#34;\u0026#34;, err } evtStr := string(evtBytes) // The string representation of an event is a json object with the sample return fmt.Sprintf(\u0026#34;{\\\u0026#34;sample\\\u0026#34;: \\\u0026#34;%s\\\u0026#34;}\u0026#34;, evtStr), nil } Defining Fields This dummy plugin has field extraction capability and exports 3 fields:\ndummy.value: the value in the event, as a uint64 dummy.strvalue: the value in the event, as a string dummy.divisible: this field takes an argument and returns 1 if the value in the event is divisible by the argument (a numeric divisor). For example, if the value was 12, dummy.divisible[3] would return 1 for that event. The Fields() method returns a slice of sdk.FieldEntry representing all the supported fields.\nfunc (m *Plugin) Fields() []sdk.FieldEntry { return []sdk.FieldEntry{ { Type: \u0026#34;uint64\u0026#34;, Name: \u0026#34;dummy.divisible\u0026#34;, Desc: \u0026#34;Return 1 if the value is divisible by the provided divisor, 0 otherwise\u0026#34;, Arg: sdk.FieldEntryArg{IsRequired: true, IsKey: true}, }, { Type: \u0026#34;uint64\u0026#34;, Name: \u0026#34;dummy.value\u0026#34;, Desc: \u0026#34;The sample value in the event\u0026#34;, }, { Type: \u0026#34;string\u0026#34;, Name: \u0026#34;dummy.strvalue\u0026#34;, Desc: \u0026#34;The sample value in the event, as a string\u0026#34;, }, } } Extracting Fields The Extract method extracts all of the supported fields. The req parameter allows accessing all the info regarding the field request, such as the field id or name, and the optional user-passed argument. The evt parameter is an interface that helps reading the event info and data.\nThe extracted field value must be set through the SetValue method of sdk.ExtractRequest. Returning from Extract without calling SetValue will signal the SDK that the requested field is not present in the given event.\nfunc (m *Plugin) Extract(req sdk.ExtractRequest, evt sdk.EventReader) error { evtBytes, err := ioutil.ReadAll(evt.Reader()) if err != nil { return err } evtStr := string(evtBytes) evtVal, err := strconv.Atoi(evtStr) if err != nil { return err } switch req.FieldID() { case 0: // dummy.divisible divisor, err := strconv.Atoi(req.ArgKey()) if err != nil { return fmt.Errorf(\u0026#34;argument to dummy.divisible %s could not be converted to number\u0026#34;, req.ArgKey()) } if evtVal%divisor == 0 { req.SetValue(uint64(1)) } else { req.SetValue(uint64(0)) } case 1: // dummy.value req.SetValue(uint64(evtVal)) case 2: // dummy.strvalue req.SetValue(evtStr) default: return fmt.Errorf(\u0026#34;no known field: %s\u0026#34;, req.Field()) } return nil } Running the Plugin This plugin can be configured in Falco by adding the following to falco.yaml file:\nplugins: - name: dummy library_path: /tmp/my-plugins/dummy/libdummy.so init_config: jitter: 10 open_params: \u0026#39;{\u0026#34;start\u0026#34;: 1, \u0026#34;maxEvents\u0026#34;: 20}\u0026#39; ## Optional load_plugins: [dummy] This simple rule prints a Falco alert any time the event number is between 0 and 10, and the sample value is divisible by 3:\n- rule: My Dummy Rule desc: My Desc condition: evt.num \u0026gt; 0 and evt.num \u0026lt; 10 and dummy.divisible[3] = 1 output: A dummy event | event=%evt.plugininfo sample=%dummy.value sample_str=%dummy.strvalue num=%evt.num priority: INFO source: dummy Here's what it looks like when run:\n$ ./falco -r ../falco-files/dummy_rules.yaml -c ../falco-files/falco.yaml Wed Feb 2 16:26:35 2022: Falco version 0.31.0 (driver version 319368f1ad778691164d33d59945e00c5752cd27) Wed Feb 2 16:26:35 2022: Falco initialized with configuration file ../falco-files/falco.yaml Wed Feb 2 16:26:35 2022: Loading plugin (dummy) from file /tmp/my-plugins/dummy/libdummy.so Wed Feb 2 16:26:35 2022: Loading rules from file ../rules/dummy_rules.yaml: Wed Feb 2 16:26:35 2022: Starting internal webserver, listening on port 8765 16:26:35.527827816: Notice A dummy event (event={\u0026#34;sample\u0026#34;: \u0026#34;6\u0026#34;} sample=6 sample_str=6 num=1) 16:26:35.527829658: Notice A dummy event (event={\u0026#34;sample\u0026#34;: \u0026#34;18\u0026#34;} sample=18 sample_str=18 num=3) 16:26:35.527831048: Notice A dummy event (event={\u0026#34;sample\u0026#34;: \u0026#34;33\u0026#34;} sample=33 sample_str=33 num=8) Events detected: 3 Rule counts by severity: INFO: 3 Triggered rules by rule name: My Dummy Rule: 3 Syscall event drop monitoring: - event drop detected: 0 occurrences - num times actions taken: 0 ","summary":"","tags":null,"title":"Falco Plugins Go SDK Walkthrough","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/plugins/go-sdk-walkthrough/"},{"category":"docs","content":"Falco alerts can easily be forwarded to third-party systems. Their JSON format allows them to be easily consumed for storage, analysis and reaction.\nFalcosidekick Falcosidekick is a proxy forwarder that acts as a central point for any fleet of Falco instances, using their HTTP outputs to send alerts.\nIt supports forwarding alerts to various outputs such as chat platforms, alerting systems, logs, storage services, and streaming systems.\nFalcosidekick can also add custom fields to the alerts, filter them by priority and expose a Prometheus metrics endpoint.\nThe full documentation and the project repository are here.\nFalcosidekick can be deployed with Falco in Kubernetes clusters with the official Falco Helm chart.\nIts configuration can be made through a yaml file and/or env vars.\nOutputs Follow the links to know what are the settings of each output. The available outputs in Falcosidekick are:\nChat\nSlack Rocketchat Mattermost Teams Webex Discord Google Chat Zoho Cliq Telegram Metrics / Observability\nDatadog Influxdb StatsD (for monitoring of falcosidekick) DogStatsD (for monitoring of falcosidekick) Prometheus (for both events and monitoring of falcosidekick) Wavefront Spyderbat TimescaleDB Dynatrace OTEL Metrics (for both events and monitoring of falcosidekick) Alerting\nAlertManager Opsgenie PagerDuty Grafana OnCall Logs\nElasticsearch Loki AWS CloudWatchLogs Grafana Syslog Zincsearch OpenObserve SumoLogic Quickwit Datadog Logs Object Storage\nAWS S3 GCP Storage Yandex S3 Storage FaaS / Serverless\nAWS Lambda GCP Cloud Run GCP Cloud Functions Fission KNative (CloudEvents) Kubeless OpenFaaS Tekton Message queue / Streaming\nNATS STAN (NATS Streaming) AWS SQS AWS SNS AWS Kinesis GCP PubSub Apache Kafka Kafka Rest Proxy RabbitMQ Azure Event Hubs Yandex Data Streams MQTT Gotify Email\nSMTP Database\nRedis Web\nWebhook Node-RED WebUI SIEM\nAWS Security Lake Workflow\nn8n Traces\nOTEL Traces Response engine\nFalco Talon Other\nPolicy Report Installation in Kubernetes with Helm See the available Helm values to configure Falcosidekick.\nhelm install falco falcosecurity/falco \\ -n falco --create-namespace \\ --set falcosidekick.enabled=true \\ --set tty=true Installation in Docker Use the env vars to configure Falcosidekick.\ndocker run -d -p 2801:2801 -e SLACK_WEBHOOKURL=XXXX falcosecurity/falcosidekick:2.27.0 Installation on the host Adapt the version and the architecture to your environment. You can find all the releases here.\nsudo mkdir -p /etc/falcosidekick wget https://github.com/falcosecurity/falcosidekick/releases/download/2.27.0/falcosidekick_2.27.0_linux_amd64.tar.gz \u0026amp;\u0026amp; sudo tar -C /usr/local/bin/ -xzf falcosidekick_2.27.0_linux_amd64.tar.gz See the example config file to create your own in /etc/falcosidekick/config.yaml.\nTo enable and start the service, you can use a systemd unit /etc/systemd/system/falcosidekick.service like this one:\n[Unit] Description=Falcosidekick After=network.target StartLimitIntervalSec=0 [Service] Type=simple Restart=always RestartSec=1 ExecStart=/usr/local/bin/falcosidekick -c /etc/falcosidekick/config.yaml EOF systemctl enable falcosidekick systemctl start falcosidekick Falcosidekick UI Falcosidekick comes with its own interface to visualize the events and get statistics.\nInstallation in Kubernetes with Helm You can install the UI at the same moment as Falcosidekick by adding the argument --set falcosidekick.webui.enabled=true.\nhelm install falco falcosecurity/falco \\ -n falco --create-namespace \\ --set falcosidekick.enabled=true \\ --set falcosidekick.webui.enabled=true \\ --set tty=true Then create a port-forward to access it: kubectl port-forward svc falco-falcosidekick-ui 2802:2802 -n falco. The default credentials are admin/admin.\nThe full documentation and the repository of the project are here.\n","summary":"","tags":null,"title":"Alerts Forwarding","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/outputs/forwarding/"},{"category":"docs","content":"The Falco cloudtrail plugin can read AWS CloudTrail logs and emit events for each CloudTrail log entry.\nThis plug-in also includes out-of-the-box rules that can be used to identify interesting/suspicious/notable events in CloudTrail logs, including:\nConsole logins that do not use multi-factor authentication Disabling multi-factor authentication for users Disabling encryption for S3 buckets Configuration See the README for information on how to configure the plugin. The plugin initialization and open params strings/objects can be added to falco.yaml under the plugins configuration key.\nMethods to read AWS CloudTrail logs The plugin can be configured to read log files from:\nA S3 bucket A SQS queue that passes along SNS notifications about new log files A local filesystem path For more information on the open params syntax, see open params.\nTerraform Module for CloudTrail | Prerequisites In order to use the AWS CloudTrail plugin, you must enable CloudTrail logging for the account(s) you want to monitor. This must be done before using the plugin.\nIn addition, of the three options above, using an SQS queue provides the easiest-to-consume source of logs. With the SQS queue, the plugin can detect when the new log files are written and can automatically consume them.\nHowever, this also requires creating multiple AWS cloud resources, such as SQS queues, SNS topics/subscriptions, IAM policy documents, etc., outside of Falco, which involve multiple manual steps.\nTo make this process easier, we've created a Terraform module that automatically creates these resources.\n","summary":"","tags":null,"title":"CloudTrail Events","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/event-sources/plugins/cloudtrail/"},{"category":"docs","content":" This document provides advanced performance tuning options for the syscall data source in Falco. It is intended for users who want to optimize the performance of their Falco deployment by customizing the syscall monitoring behavior.\nAdaptive syscalls selection Falco provides users flexibility to select different syscall monitoring behaviors tailored to their specific use cases. These options offer various degrees of control over system calls, directly configured through the falco.yaml file.\nThis section outlines the available configurations and their implications.\nDefault behavior By default, Falco traces syscalls derived from:\nSyscalls explicitly required by enabled Falco rules. A predefined set essential for maintaining Falco's internal state engine, defined at compile-time. With the default configuration:\nbase_syscalls.custom_set: [] base_syscalls.repair: false base_syscalls.all: false This ensures accurate state engine management but offers no end-user customization of the additional syscalls.\nMonitoring all syscalls (base_syscalls.all) Setting this option to true enables monitoring all events supported by Falco, including typically ignored events such as write:\nbase_syscalls.all: true Use with caution, as this may negatively impact performance due to increased resource usage.\nUser-defined syscall set (base_syscalls.custom_set) CAUTION: Misconfiguration may result in incomplete event logs or disrupt Falco's tracing capabilities.\nThis option allows you to explicitly define an additional set of syscalls to trace, supplementing those required by active Falco rules:\nbase_syscalls.custom_set: [clone, clone3, fork, execve, execveat, close] It offers fine-grained control and can help optimize resource utilization according to your threat model and performance constraints.\nRecommended syscall sets for typical scenarios:\nProcess monitoring: [clone, clone3, fork, vfork, execve, execveat, close] Networking monitoring: [clone, clone3, fork, vfork, execve, execveat, close, socket, bind, getsockopt] Accurate UID/GID tracking: Add [setresuid, setsid, setuid, setgid, setpgid, setresgid, capset, chdir, chroot, fchdir] to the relevant set. Negative notation (\u0026quot;!syscall_name\u0026quot;) is supported to explicitly exclude specific syscalls.\nAutomatic state engine management (base_syscalls.repair) Recommended for most scenarios, enabling this option allows Falco to automatically select the minimal necessary set of syscalls beyond those explicitly required by enabled rules:\nbase_syscalls.repair: true base_syscalls.custom_set: [] base_syscalls.all: false This option ensures Falco's internal state engine integrity with minimal performance overhead, automatically incorporating best-practice syscall configurations.\nScenarios Different configurations address various monitoring scenarios effectively:\nMonitoring spawned processes under resource constraints\nDefault: Insufficient custom_set and repair: Both viable, but repair is recommended for automatic correctness. Monitoring spawned processes and network activity, excluding file opens\nDefault: Insufficient custom_set and repair: Both suitable, with repair ensuring automatic correctness without manual intervention. Flexible configurability for tailored monitoring\nUseful in environments requiring selective monitoring to optimize resources. Allows coexistence with other monitoring tools by minimizing duplication of work. Comprehensive syscall monitoring\nAll three configurations (default, custom_set, repair) can achieve complete syscall monitoring. Choice depends on user preference and performance trade-offs. Notes Use falco -i to list all events typically ignored in the default configuration. Events marked EF_OLD_VERSION are not generated during live monitoring but may appear in .scap files. ","summary":"","tags":null,"title":"Advanced Performance Tuning","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/event-sources/kernel/tuning/"},{"category":"docs","content":"Falco also provide Macros that should be overridden by the user to provide settings that are specific to a user's environment. The provided Macros can also be appended to in a local rules file.\nThe below macros contain values that can be overridden for a user's specific environment.\nCommon SSH Port Override this macro to reflect ports in your environment that provide SSH services.\n\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;ssh_port\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: fd.sport=22 Allowed SSH Hosts Override this macro to reflect hosts that can connect to known SSH ports (ie a bastion or jump box).\n\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;allowed_ssh_hosts\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: ssh_port User Trusted Containers Allowlist containers that are allowed to run in privileged mode.\n\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;user_trusted_containers\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: (container.image startswith sysdig/agent) Containers Allowed to Spawn Shells Allowlist containers that are allowed to spawn shells, which may be needed if containers are used in the CI/CD pipeline.\n\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;user_shell_container_exclusions\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: (never_true) Containers Allowed to Communicate with EC2 Metadata Services Allowlist containers that are allowed to communicate with the EC2 metadata service. Default: any container.\n\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;ec2_metadata_containers\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: container Kubernetes API Server Set the IP of your Kubernetes API Service here.\n\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;k8s_api_server\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: (fd.sip=\u0026quot;1.2.3.4\u0026quot; and fd.sport=8080) Containers Allowed to Communicate with the Kubernetes API Allowlist containers that are allowed to communicate with the Kubernetes API Service. Requires k8s_api_server being set.\n\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;k8s_containers\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: \u0026gt; (container.image startswith gcr.io/google_containers/hyperkube-amd64 or container.image startswith gcr.io/google_containers/kube2sky or container.image startswith sysdig/agent or container.image startswith sysdig/falco or container.image startswith sysdig/sysdig) Containers Allowed to Communicate with Kubernetes Service NodePorts \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;nodeport_containers\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: container ","summary":"","tags":null,"title":"Macros to Override","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/rules/macros-override/"},{"category":"docs","content":"Falco loads plugins based on configuration in falco.yaml. Currently, if a plugin with event sourcing capability is loaded then the only events processed are from that plugin; syscall events are disabled. There are other restrictions on loaded plugins (see below).\nLoading plugins in Falco The new plugins property in falco.yaml will define the set of plugins that Falco can load, and a new load_plugins property will control which plugins are actually loaded when Falco starts.\nHere's an example:\nplugins: - name: cloudtrail library_path: libcloudtrail.so init_config: \u0026#34;\u0026#34; open_params: \u0026#34;\u0026#34; - name: json library_path: libjson.so init_config: \u0026#34;\u0026#34; # Optional load_plugins: [cloudtrail, json] For more information, see \u0026lt;a href=\u0026quot;/docs/reference/daemon/config-options/\u0026quot;\u0026gt;Falco Config Options\u0026lt;/a\u0026gt;. The mechanics of loading a plugin are implemented in the libraries and leverage the dynamic library functionality of the operating system (dlopen/dlsym in unix, LoadLibrary/GetProcAddress in Windows). The plugin loading code also ensures that:\nThe plugin is valid, i.e. that it exports the set of expected symbols The plugin has an API version number that is compatible with the plugin framework. That only one plugin with event sourcing capability is loaded at a time for a given event source If a mix of plugins for both event sourcing and field extraction are loaded for a given event source, that the exported fields have unique names that don't overlap across plugins Event Sources and Falco Rules Falco rules already have the notion of a source, using the source property in YAML rules objects. There is primarily one kind of event source: syscall. The source property in Falco rules maps a given rule to the event source on which the rule runs.\nFor example, given a plugin providing events with source aws_cloudtrail, and a Falco rule with source property aws_cloudtrail, the rule will be evaluated for any events returned by the AWS CloudTrail plugin.\nSimilarly, a plugin with field extraction capability that includes aws_cloudtrail in its set of event sources will have the opportunity to extract information from CloudTrail events. As a result, fields exported by the plugin can be put in a rule's condition, exception, or output properties when the rule has a source aws_cloudtrail.\nFalco compiles rules/macros/lists selectively based on the set of loaded plugins (specifically, their event sources), instead of unconditionally as Falco is started. This is especially important for macros, which do not contain a source property, but might contain fields that are only implemented by a given plugin.\nPlugin Versions and Falco Rules To allow rules files to document the plugin versions they are compatible with, rules files can have a new top-level field required_plugin_versions. The field is optional, and if not provided no plugin compatibility checks will be performed. The syntax of required_plugin_versions is the following:\n- required_plugin_versions: - name: \u0026lt;plugin_name\u0026gt; version: x.y.z ... Below required_plugin_versions is a list of objects, where each object has name and version properties. If a plugin is loaded, and if an entry in required_plugin_versions has a matching name, then the loaded plugin version must be semver compatible with the version property.\nFalco can load multiple rules files, and each file may contain its own required_plugin_versions property. In this case, name+version pairs across all files will be merged, and in the case of duplicate names all provided versions must be compatible.\nPlugin Developer's Guide If you are interested in authoring your own plugin, or modifying an existing plugin to add new functionality, we've written a developer's guide that documents the full plugin APIs and walks through two existing plugins to show how the API is used.\n","summary":"","tags":null,"title":"How Falco Uses Plugins","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/plugins/usage/"},{"category":"docs","content":"First, ensure you can access a test Kubernetes cluster running with Linux nodes, either x86_64 or ARM64. Note that using Docker Desktop on Windows or macOS will not work for this purpose. Also, you will need to have kubectl and helm installed and configured.\nDeploy Falco First, install the helm repository:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update Then install Falco:\nhelm install --replace falco --namespace falco --create-namespace --set tty=true falcosecurity/falco And check that the Falco pods are running:\nkubectl get pods -n falco Falco pod(s) might need a few seconds to start. Wait until they are ready:\nkubectl wait pods --for=condition=Ready --all -n falco Falco comes with a pre-installed set of rules that alert you upon suspicious behavior.\nTrigger a rule Let's create a deployment:\nkubectl create deployment nginx --image=nginx And execute a command that would trigger a rule:\nkubectl exec -it $(kubectl get pods --selector=app=nginx -o name) -- cat /etc/shadow Now let's take a look at the Falco logs:\nkubectl logs -l app.kubernetes.io/name=falco -n falco -c falco | grep Warning You will see logs for all the Falco pods deployed on the system. The Falco pod corresponding to the node in which our nginx deployment is running has detected the event, and you'll be able to read a line like:\n09:46:05.727801343: Warning Sensitive file opened for reading by non-trusted program (file=/etc/shadow gparent=systemd ggparent=\u0026lt;NA\u0026gt; gggparent=\u0026lt;NA\u0026gt; evt_type=openat user=root user_uid=0 user_loginuid=-1 process=cat proc_exepath=/usr/bin/cat parent=containerd-shim command=cat /etc/shadow terminal=34816 container_id=bf74f1749e23 container_image=docker.io/library/nginx container_image_tag=latest container_name=nginx k8s_ns=default k8s_pod_name=nginx-7854ff8877-h97p4) This is your first Falco event 🦅! If you are curious, this is the rule that describes it.\nCreate a custom rule Now it's time to create our own rule and load it into Falco. We can be pretty creative with them, but let's stick with something simple. This time, we want to be alerted when any file is opened for writing in the /etc directory, either on the host or inside containers.\nCreate a file and call it falco_custom_rules_cm.yaml with the following content:\ncustomRules: custom-rules.yaml: |- - rule: Write below etc desc: An attempt to write to /etc directory condition: \u0026gt; (evt.type in (open,openat,openat2) and evt.is_open_write=true and fd.typechar=\u0026#39;f\u0026#39; and fd.num\u0026gt;=0) and fd.name startswith /etc output: \u0026#34;File below /etc opened for writing | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty\u0026#34; priority: WARNING tags: [filesystem, mitre_persistence] And load it into Falco:\nhelm upgrade --namespace falco falco falcosecurity/falco --set tty=true -f falco_custom_rules_cm.yaml Falco pod(s) might need a few seconds to restart. Wait until they are ready:\nkubectl wait pods --for=condition=Ready --all -n falco Then trigger our new rule:\nkubectl exec -it $(kubectl get pods --selector=app=nginx -o name) -- touch /etc/test_file_for_falco_rule And look at the logs:\nkubectl logs -l app.kubernetes.io/name=falco -n falco -c falco | grep Warning You should see a log entry like the one below:\n13:14:27.811647863: Warning File below /etc opened for writing (file=/etc/test_file_for_falco_rule pcmdline=containerd-shim -namespace k8s.io -id d5438fedb274ac82963d99987313dae8da512236ace2f70472a772d95090b607 -address /run/containerd/containerd.sock gparent=systemd ggparent=\u0026lt;NA\u0026gt; gggparent=\u0026lt;NA\u0026gt; evt_type=openat user=root user_uid=0 user_loginuid=-1 process=touch proc_exepath=/usr/bin/touch parent=containerd-shim command=touch /etc/test_file_for_falco_rule terminal=34816 container_id=bf74f1749e23 container_image=docker.io/library/nginx container_image_tag=latest container_name=nginx k8s_ns=default k8s_pod_name=nginx-7854ff8877-h97p4) Deploy Falcosidekick and Falcosidekick UI In the previous step we displayed the rule output by examining the Falco log for the pod in the cluster that is running on the node. Now we will see how we can forward these alerts to a custom location or display them in a clean GUI. There are many ways to accomplish this but one is by using Falcosidekick which can easily be deployed with the same Helm chart.\nInstall Falcosidekick and Falcosidekick-UI in your test cluster:\nhelm upgrade --namespace falco falco falcosecurity/falco -f falco_custom_rules_cm.yaml --set falcosidekick.enabled=true --set falcosidekick.webui.enabled=true Now check that it is running and its service is set up:\nkubectl -n falco get svc You should see something like this:\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE falco-falcosidekick ClusterIP 10.43.212.119 \u0026lt;none\u0026gt; 2801/TCP 61s falco-falcosidekick-ui ClusterIP 10.43.35.87 \u0026lt;none\u0026gt; 2802/TCP 60s Display events in the Falcosidekick UI Forward the UI port, which is 2802:\nkubectl -n falco port-forward svc/falco-falcosidekick-ui 2802 And point your browser to http://localhost:2802 . The default username and password are admin / admin.\nNow click on \u0026quot;Events\u0026quot; on top of the page and trigger an event again:\nkubectl exec -it $(kubectl get pods --selector=app=nginx -o name) -- cat /etc/shadow You should see an event appearing in the Falcosidekick UI\nThe Falcosidekick UI can be used to quickly display events but most likely on a production system you will want to forward events to a centralized location. Falcosidekick supports more than 60 integrations. You can find an example below but you can refer to the forwarding documentation to learn more.\nForward events to a Slack webhook Deploy Falco again, this time disabling the web UI and enabling Slack forwarding. Of course, you can enable both if you wish.\nhelm upgrade --namespace falco falco falcosecurity/falco \\ --set falcosidekick.enabled=true \\ --set falcosidekick.config.slack.webhookurl=YOUR_WEBHOOK_URL_HERE \\ --set falcosidekick.config.slack.minimumpriority=notice If Slack is configured correctly, when an event is triggered you should receive a message like the following:\nCleanup If you wish to remove Falco from your cluster you can simply run:\nhelm -n falco uninstall falco ","summary":"","tags":null,"title":"Try Falco on Kubernetes","url":"https://v0-43--falcosecurity.netlify.app/docs/getting-started/falco-kubernetes-quickstart/"},{"category":"docs","content":"This document describes the overall architecture that allows events from kernel sources to be ingested by Falco, how to use the libraries to inspect the data collection flow and how Falco manages the boundary between the kernel and userspace. In order to make Falco compatible with a very large number of Linux Kernel versions, the internal APIs and low level communication mechanisms that are employed to cross the kernel and userspace boundary vary greatly between driver types and may be different between driver versions or kernel versions. However, they all implement the same event collection interface as described below.\nHow Falco interacts with kernel components The component of the Falco libraries that gathers data from the syscalls and interacts with the kernel is called libscap. Internally, it implements all functionality required to use the drivers to collect kernel events.\nWhen using the kernel module or legacy eBPF probe (deprecated), the driver will need to be installed and deployed separately as a kernel object or probe, while the modern eBPF probe can be installed directly by libscap.\nUpon connection to its kernel counterpart, libscap will need to negotiate the API Version and Schema Version that the driver recognizes. These versions are expressed with a semver subset and are documented in the libs repository.\nThe API version refers to the communication mechanism between the kernel and userspace. Every driver has a different communication mechanism which changes between versions. The kernel module may use ioctls and a ring buffer, while the eBPF probe can use maps and different APIs depending on the kernel version and eBPF probe edition. Since some drivers can be deployed separately from Falco, at startup libscap will verify if the driver it's connecting to is compatible. The Schema version refers to the type of events that the specific driver supports. The Syscall Events documentation page shows the list of fields that are supported for each version of Falco. Every time that list changes the version number is updated as well. When running Falco it is possible to verify the currently compatible version numbers with falco --version. For instance, this is the output for Falco 0.35.1:\n# falco --version 2023-07-01T16:23:43+0000: Falco version: 0.35.1 (x86_64) 2023-07-01T16:23:43+0000: Falco initialized with configuration file: /etc/falco/falco.yaml Falco version: 0.35.1 Libs version: 0.11.3 Plugin API: 3.0.0 Engine: 17 Driver: API version: 4.0.0 Schema version: 2.0.0 Default driver: 5.0.1+driver Once Falco is running, a stream of events is returned directly from the kernel. libscap's API allow the data to flow with a consistent format from the kernel to userspace.\nThe main interface that governs this is the scap event format. Once the chosen driver is loaded and initialized in the kernel, the events are encoded with a specific header and a payload:\nstruct ppm_evt_hdr { uint64_t ts; /* timestamp, in nanoseconds from epoch */ uint64_t tid; /* the tid of the thread that generated this event */ uint32_t len; /* the event len, including the header */ uint16_t type; /* the event type */ uint32_t nparams; /* the number of parameters of the event */ }; The payload contains an array of lengths of each parameter followed by the content of the parameters themselves. The parameter type is a numeric identifer that maps with each event documented in the reference.\nFor example, the dup3 event is defined in the reference as:\ndup3(FD res, FD oldfd, FD newfd, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE)\nMeaning that its encoding will be composed of an header containing the timestamp and tid, nparams will be 4 and the complete encoding will be:\n[header] [uint16(8)] [uint16(8)] [uint16(8)] [uint16(32)] [res] [oldfd] [newfd] [flags] Use scap-open to inspect kernel data collection Contributors and expert users can find a tool called scap-open in the libs repo. This tool allows to dump raw events from a variety of drivers. Building and usage instructions are included in the repository.\n","summary":"","tags":null,"title":"Kernel Events Architecture","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/event-sources/kernel/architecture/"},{"category":"docs","content":"You can open a PR against the rules repo to share your rule with the community. The PR review process ensures that the rules align with the project's best interests as per our governance, follow the style guide, and meet the additional requirements, including testing and maturity level outlined in the rules repo contributing guide. Reviewers will support you throughout the process.","summary":"","tags":null,"title":"How to Share Your Falco Rules","url":"https://v0-43--falcosecurity.netlify.app/docs/contribute/share-rules/"},{"category":"docs","content":"Previous guides introduced the Output Fields of Falco Rules and provided Guidelines on how to use them. This section highlights additional global formatting options for your deployment, complementing the information previously provided.\nAdding the same output field to multiple rules by manually editing rule files can be tedious. Fortunately, Falco provides several ways to simplify this process:\nUsing the append_output configuration option in falco.yaml to add output text or fields to a subset of loaded rules Adding an override to a specific rule to replace its output Appending Extra Output and Fields with append_output The append_output option can be specified in the falco.yaml configuration file. You can use it to add extra output to rules specified by source, tag, name, or to all rules unconditionally. The append_output section is a list of items that are applied in the order they appear.\nExample:\nappend_output: - match: source: syscall extra_output: \u0026#34;on CPU %evt.cpu\u0026#34; extra_fields: - home_directory: \u0026#34;${HOME}\u0026#34; - evt.hostname In this example:\nEvery rule with the syscall source will have on CPU %evt.cpu appended at the end of the regular output line. The rule will also include the additional fields (home_directory and evt.hostname) in the JSON output under output_fields. These extra fields do not appear in the regular (text) output. Environment variables (like $HOME) expansion is supported in the configuration file, so for extra_fields as well. Matching Rules The match section allows you to filter which rules are modified:\nsource: filters rules by source (e.g., syscall or plugin names) rule: filters by the complete rule name tags: filters by a list of tags (all listed tags must be present) If multiple conditions are specified under match, all must be met for the entry to apply. If no conditions are specified—or match is omitted—then the entry applies to all rules.\nAdding an Override to a Specific Rule Note that append_output only adds output to an existing rule; it does not remove or replace existing fields. To remove or replace output fields, you can add another rule file (loaded after the original) that uses an override. For example:\n- rule: Read sensitive file trusted after startup output: A file (user=%user.name command=%proc.cmdline file=%fd.name) was read after startup override: output: replace Suggested Output Fields By default, Falco can also include \u0026quot;suggested\u0026quot; fields from plugins implementing the extraction capabilities. This is especially useful if certain plugins mark some fields as recommended for output. Those fields will appear automatically in your alerts.\nBelow is an example configuration entry that enables suggested output fields unconditionally for any source:\nappend_output: - suggested_output: true # Enable the use of extractor plugins\u0026#39; suggested fields for all matching sources. When suggested_output is set to true, any extractor plugin that provides \u0026quot;suggested\u0026quot; fields will add them to the output in the form plugin_field_name=$plugin.field_name.\nCommand-Line Usage You can also specify this option on the command line via the -o flag, for example:\nfalco ... \\ -o \u0026#39;append_output[]={\u0026#34;match\u0026#34;: {\u0026#34;source\u0026#34;: \u0026#34;syscall\u0026#34;}, \u0026#34;extra_output\u0026#34;: \u0026#34;on CPU %evt.cpu\u0026#34;, \u0026#34;extra_fields\u0026#34;: [\u0026#34;evt.hostname\u0026#34;]}\u0026#39; ","summary":"","tags":null,"title":"Alert Formatting","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/outputs/formatting/"},{"category":"docs","content":"Action Items (TL;DR) Adjust the buf_size_preset in the falco.yaml config. Utilize base_syscalls to limit the syscalls under monitoring. Audit and optimize Falco rules to prevent unnecessary backpressure on the kernel, considering that Falco's main event stream is single-threaded. Try running Falco without any plugins. Background Falco monitors each syscall based on deployed Falco rules. Additionally, Falco requires a few more syscalls to function properly, see Adaptive Syscalls Selection:\nThe default configuration is conservative; consequently, there is an opportunity that you could optimize and even eliminate Falco dropping events, depending on the scope of monitoring you are seeking. Utilize the base_syscalls config for precise override control alongside a resource-friendly suggestion of the absolute minimum additional syscalls needed to ensure proper functioning of Falco (set repair: true). Falco monitors syscalls by hooking into kernel tracepoints. To transfer events from the kernel to userspace, it uses buffers. For each CPU, Falco allocates separate buffers. If you're using the modern_ebpf driver, you can choose to have fewer, larger buffers shared among multiple CPUs (contention, according to kernel experts, should not be a problem). The buffer size is fixed but can be adjusted in the buf_size_preset config. Increasing the size helps, but keep in mind that the benefits may not increase proportionally. Also, remember that a larger buffer means more preallocated memory.\nbuf_size_preset of 5 or 6 could be a valid option for large machines assuming you use the kmod or ebpf drivers. For the modern_ebpf driver try a modern_ebpf.buf_size_preset of 6 or 7, along with a modern_ebpf.cpus_for_each_buffer of 4 or 6. Feel free to experiment and adjust these values as needed. Lastly, while it may sound appealing to push all filtering into the kernel, it is not that straightforward. In the kernel, you are in the application context, and yes, you can slow down both the kernel and the application (for example, apps may then experience lower request rates). Checkout the Driver Kernel Testing Framework for more information. Additionally, in the kernel, you only have raw syscall arguments and can't easily correlate them with other events. All this being said, we are actively looking into ways to improve this and make the kernel logic smarter without sacrificing performance.\nKernel-side Syscalls Drops Metrics Falco's metrics config (see also Falco Metrics) enables you to measure Falco's kernel-side syscall drops and provides a range of useful metrics related to software functioning. Key settings include:\nkernel_event_counters_enabled: true libbpf_stats_enabled: true (for ebpf or modern_ebpf drivers, enable /proc/sys/kernel/bpf_stats_enabled) Here is an example metrics log snippet highlighting the fields crucial for this analysis. Pay close attention to falco.evts_rate_sec and scap.evts_rate_sec, as well as the monotonic drop counters categorizing syscalls into coarse-grained (non-comprehensive) categories. For more details, refer to the dedicated metrics section in the Falco Performance guide for a more detailed explanation.\n{ \u0026#34;output_fields\u0026#34;: { \u0026#34;evt.source\u0026#34;: \u0026#34;syscall\u0026#34;, \u0026#34;falco.host_num_cpus\u0026#34;: 96, # Divide *rate_sec by CPUs \u0026#34;falco.evts_rate_sec\u0026#34;: 93345.1, # Taken between 2 metrics snapshots \u0026#34;falco.num_evts\u0026#34;: 44381403800, \u0026#34;falco.num_evts_prev\u0026#34;: 44045361392, # scap kernel-side counters \u0026#34;scap.evts_drop_rate_sec\u0026#34;: 0.0, # Taken between 2 metrics snapshots \u0026#34;scap.evts_rate_sec\u0026#34;: 93546.8, # Taken between 2 metrics snapshots \u0026#34;scap.n_drops\u0026#34;: 0, # Monotonic counter all-time kernel side drops # Coarse-grained (non-comprehensive) categories for more granular insights \u0026#34;scap.n_drops_buffer_clone_fork_exit\u0026#34;: 0, \u0026#34;scap.n_drops_buffer_close_exit\u0026#34;: 0, \u0026#34;scap.n_drops_buffer_connect_enter\u0026#34;: 0, \u0026#34;scap.n_drops_buffer_connect_exit\u0026#34;: 0, \u0026#34;scap.n_drops_buffer_dir_file_exit\u0026#34;: 0, \u0026#34;scap.n_drops_buffer_execve_exit\u0026#34;: 0, \u0026#34;scap.n_drops_buffer_open_enter\u0026#34;: 0, \u0026#34;scap.n_drops_buffer_open_exit\u0026#34;: 0, \u0026#34;scap.n_drops_buffer_other_interest_exit\u0026#34;: 0, \u0026#34;scap.n_drops_buffer_proc_exit\u0026#34;: 0, \u0026#34;scap.n_drops_buffer_total\u0026#34;: 0, \u0026#34;scap.n_drops_bug\u0026#34;: 0, \u0026#34;scap.n_drops_page_faults\u0026#34;: 0, \u0026#34;scap.n_drops_perc\u0026#34;: 0.0, # Taken between 2 metrics snapshots \u0026#34;scap.n_drops_prev\u0026#34;: 0, \u0026#34;scap.n_drops_scratch_map\u0026#34;: 0, \u0026#34;scap.n_evts\u0026#34;: 48528636923, \u0026#34;scap.n_evts_prev\u0026#34;: 48191868502, # libbpf stats -\u0026gt; all-time kernel tracepoints invocations stats for a x86_64 machine \u0026#34;scap.sched_process_e.avg_time_ns\u0026#34;: 2041, # scheduler process exit tracepoint \u0026#34;scap.sched_process_e.run_cnt\u0026#34;: 151463770, \u0026#34;scap.sched_process_e.run_time_ns\u0026#34;: 181866667867268, \u0026#34;scap.sys_enter.avg_time_ns\u0026#34;: 194, # syscall enter (raw) tracepoint \u0026#34;scap.sys_enter.run_cnt\u0026#34;: 933995602769, \u0026#34;scap.sys_enter.run_time_ns\u0026#34;: 181866667867268, \u0026#34;scap.sys_exit.avg_time_ns\u0026#34;: 205, # syscall exit (raw) tracepoint \u0026#34;scap.sys_exit.run_cnt\u0026#34;: 934000454069, \u0026#34;scap.sys_exit.run_time_ns\u0026#34;: 192201218598457 }, \u0026#34;rule\u0026#34;: \u0026#34;Falco internal: metrics snapshot\u0026#34; } Precise Control Over Monitored Syscalls Since Falco 0.35.0, you have precise control over the syscalls Falco monitors. Refer to the Adaptive Syscalls Selection blog post and carefully read the base_syscalls config description for detailed information.\nRun Tests for Data-Driven Insights Falco's current metrics system lacks direct syscalls counters to pinpoint high-volume culprits. In the meantime, deriving insights step by step is necessary until syscall counters become available in Falco's metrics system.\nGenerate a dummy rule designed not to trigger any alerts:\n- macro: spawned_process condition: (evt.type in (execve, execveat)) - rule: TEST Simple Spawned Process desc: \u0026#34;Test base_syscalls config option\u0026#34; enabled: true condition: spawned_process and proc.name=iShouldNeverAlert output: \u0026#34;%evt.type\u0026#34; priority: WARNING Now, run Falco with the dummy rule and the specified test cases (edit base_syscalls config). If you're open to it, consider sharing anonymized logs for further assessment by Falco maintainers or the community to explore potential solutions.\nFor each test, run Falco in dry-run debug mode initially to print the final set of syscalls.\nsudo /usr/bin/falco -c /etc/falco/falco.yaml -r falco_rules_dummy.yaml -o \u0026#34;log_level=debug\u0026#34; -o \u0026#34;log_stderr=true\u0026#34; --dry-run # Example Output for Test 2 XXX: (2) syscalls in rules: execve, execveat XXX: +(16) syscalls (Falco\u0026#39;s state engine set of syscalls): capset, chdir, chroot, clone, clone3, fchdir, fork, prctl, procexit, setgid, setpgid, setresgid, setresuid, setsid, setuid, vfork XXX: (18) syscalls selected in total (final set): capset, chdir, chroot, clone, clone3, execve, execveat, fchdir, fork, prctl, procexit, setgid, setpgid, setresgid, setresuid, setsid, setuid, vfork Subsequently, run Falco normally.\nsudo /usr/bin/falco -c /etc/falco/falco.yaml -r falco_rules_dummy.yaml Test 1: spawned_process only\nbase_syscalls: custom_set: [clone, clone3, fork, vfork, execve, execveat, procexit] repair: false If Test 1 already fails, and you see drops even after adjusting the buf_size_preset and other parameters, Falco may be less usable on this particular system, unfortunately.\nTest 2: spawned_process + minimum syscalls needed for Falco state (internal process cache table)\nbase_syscalls: custom_set: [] repair: true Test 3: network accept*\nbase_syscalls: custom_set: [clone, clone3, fork, vfork, execve, execveat, getsockopt, socket, bind, accept, accept4, close] repair: false Test 4: network connect\nbase_syscalls: custom_set: [clone, clone3, fork, vfork, execve, execveat, getsockopt, socket, connect, close] repair: false Test 5: open* syscalls\nbase_syscalls: custom_set: [clone, clone3, fork, vfork, execve, execveat, open, openat, openat2, close] repair: false Test n\nContinue custom testing to ensure effective monitoring of all desired syscalls on your servers without experiencing event drops or with minimal acceptable drops.\nAt What Kernel Event Rates Do Problems Generally Start? This question presents a challenge as it's not solely about the pure \u0026quot;kernel event rate\u0026quot;. In less realistic benchmarking tests, you could artificially drive the rates very high without dropping events. Therefore, we believe it is more complex in real-life production, involving not just event rates but also the actual nature of the events, and possibly bursts of events in very short periods of time.\nAdditionally, we believe it's best to normalize the event rates by the number of CPUs (e.g. scap.evts_rate_sec / falco.host_num_cpus). Busier servers with 96, 128, or more CPUs naturally have higher event rates than VMs with 12 CPUs, for instance.\nNevertheless, here are some numbers we have heard from various adopters. Please take them with a grain of salt:\nLess than ~1K kernel events per second per one CPU usually is not a problem, but it depends. Less than ~1.5K kernel events per second per one CPU should not be a problem, but it depends. More than 3K kernel events per second per one CPU likely could be more difficult to keep up, but it depends. Consider 1-2% of all events dropped on a smaller subset of servers in your fleet (your busy servers/clusters) as acceptable. More than 164K kernel events per second per CPU have been observed on a 128-CPU machine. Currently under exploration is how to solve this. References and Community Discussions Introduce conditional kernel-side event filtering New base_syscalls.exclude_enter_exit_set config Improve falco benchmarking, performance, and regression tooling to better track system resources impact [UMBRELLA] Dropped events Adaptive Syscalls Selection ","summary":"","tags":null,"title":"Falco Is Dropping Syscalls Events","url":"https://v0-43--falcosecurity.netlify.app/docs/troubleshooting/dropping/"},{"category":"docs","content":"This page lists all arguments you can pass to Falco in your command line:\nFalco Arguments \u0026lt;pre tabindex=\u0026quot;0\u0026quot;\u0026gt;\u0026lt;code\u0026gt;Falco - Cloud Native Runtime Security Usage: falco [OPTION...]\n-h, --help Print this help list and exit. -c \u0026lt;path\u0026gt; Configuration file. If not specified tries /etc/falco/falco.yaml. --config-schema Print the config json schema and exit. --rule-schema Print the rule json schema and exit. --disable-source \u0026lt;event_source\u0026gt; Turn off a specific \u0026lt;event_source\u0026gt;. By default, all loaded sources get enabled. Available sources are 'syscall' plus all sources defined by loaded plugins supporting the event sourcing capability. This option can be passed multiple times, but turning off all event sources simultaneously is not permitted. This option can not be mixed with --enable-source. This option has no effect when reproducing events from a capture file. --dry-run Run Falco without processing events. It can help check that the configuration and rules do not have any errors. --enable-source \u0026lt;event_source\u0026gt; Enable a specific \u0026lt;event_source\u0026gt;. By default, all loaded sources get enabled. Available sources are 'syscall' plus all sources defined by loaded plugins supporting the event sourcing capability. This option can be passed multiple times. When using this option, only the event sources specified by it will be enabled. This option can not be mixed with --disable-source. This option has no effect when reproducing events from a capture file. --gvisor-generate-config [=\u0026lt;socket_path\u0026gt;(=/run/falco/gvisor.sock)] DEPRECATED: Generate a configuration file that can be used for gVisor and exit. See --gvisor-config for more details. -i Print those events that are ignored by default for performance reasons and exit. -L Show the name and description of all rules and exit. If json_output is set to true, it prints details about all rules, macros, and lists in JSON format. -l \u0026lt;rule\u0026gt; Show the name and description of the rule specified \u0026lt;rule\u0026gt; and exit. If json_output is set to true, it prints details about the rule in JSON format. --list [=\u0026lt;source\u0026gt;(=)] List all defined fields and exit. If \u0026lt;source\u0026gt; is provided, only list those fields for the source \u0026lt;source\u0026gt;. Current values for \u0026lt;source\u0026gt; are \u0026quot;syscall\u0026quot; or any source from a configured plugin with event sourcing capability. --list-events List all defined syscall events, metaevents, tracepoint events and exit. --list-plugins Print info on all loaded plugins and exit. -M \u0026lt;num_seconds\u0026gt; Stop Falco execution after \u0026lt;num_seconds\u0026gt; are passed. (default: 0) --markdown Print output in Markdown format when used in conjunction with --list or --list-events options. It has no effect when used with other options. -N Only print field names when used in conjunction with the --list option. It has no effect when used with other options. -o, --option \u0026lt;opt\u0026gt;=\u0026lt;val\u0026gt; Set the value of option \u0026lt;opt\u0026gt; to \u0026lt;val\u0026gt;. Overrides values in the configuration file. \u0026lt;opt\u0026gt; can be identified using its location in the configuration file using dot notation. Elements of list entries can be accessed via square brackets []. E.g. base.id = val base.subvalue.subvalue2 = val base.list[1]=val --plugin-info \u0026lt;plugin_name\u0026gt; Print info for the plugin specified by \u0026lt;plugin_name\u0026gt; and exit. This includes all descriptive information like name and author, along with the schema format for the init configuration and a list of suggested open parameters. \u0026lt;plugin_name\u0026gt; can be the plugin's name or its configured 'library_path'. -p, --print \u0026lt;output_format\u0026gt; DEPRECATED: use -o append_output... instead. Print additional information in the rule's output. Use -pc or -pcontainer to append container details to syscall events. Use -pk or -pkubernetes to add both container and Kubernetes details to syscall events. The details will be directly appended to the rule's output. Alternatively, use -p \u0026lt;output_format\u0026gt; for a custom format. In this case, the given \u0026lt;output_format\u0026gt; will be appended to the rule's output without any replacement to all events, including plugin events. -P, --pidfile \u0026lt;pid_file\u0026gt; Write PID to specified \u0026lt;pid_file\u0026gt; path. By default, no PID file is created. (default: \u0026quot;\u0026quot;) -r \u0026lt;rules_file\u0026gt; Rules file or directory to be loaded. This option can be passed multiple times. Falco defaults to the values in the configuration file when this option is not specified. Only files with .yml or .yaml extension are considered. --support Print support information, including version, rules files used, loaded configuration, etc., and exit. The output is in JSON format. -U, --unbuffered Turn off output buffering for configured outputs. This causes every single line emitted by Falco to be flushed, which generates higher CPU usage but is useful when piping those outputs into another process or a script. -V, --validate \u0026lt;rules_file\u0026gt; Read the contents of the specified \u0026lt;rules_file\u0026gt; file(s), validate the loaded rules, and exit. This option can be passed multiple times to validate multiple files. -v Enable verbose output. --version Print version information and exit. --page-size Print the system page size and exit. This utility may help choose the right syscall ring buffer size. ","summary":"","tags":["Falco Daemon"],"title":"Falco Daemon Arguments","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/daemon/cli-arguments/"},{"category":"docs","content":"Introduction In this article, we'll focus on the steps to build the OCI artifacts containing the plugin and its rules and how to distribute them on Github Packages.\nTo get more familiar with the OCI artifacts, you can read our blog posts about falcoctl and GitOps for rules\nIn the next sections we'll describe how to:\nset up a Github Actions workflow to: create a release with GoReleaser when a tag is pushed build the OCI artifacts of the plugin and its rules create the index.yaml used by falcoctl Requirements This tutorial is based on a Github repo, with the possibility to run workflows in Github Actions and store OCI artifacts in Github Packages. If you use a different system or even just private repositories, you'll need to adapt the examples to your context.\nTo make it work, you must have the code organization proposed in how to develop a plugin page.\nGoReleaser GoReleaser is a famous tool to build and create releases for projects on Github or else. We'll use it to build and archive the binaries at each release.\nAt the root of your repo, create a .goreleaser.yaml file with the following content:\nbuilds: - env: - GODEBUG=cgocheck=0 main: ./plugin binary: lib{PLUGIN_NAME}.so goos: - linux goarch: - amd64 flags: -buildmode=c-shared checksum: name_template: \u0026#34;checksums.txt\u0026#34; With PLUGIN_NAME as the name of your plugin.\nMakefile Makefiles are a convenient way to script actions. We'll use it to pass all the required flags to create the final .so library files used by the Falco plugin framework:\nSHELL=/bin/bash -o pipefail GO ?= go NAME := {PLUGIN_NAME} OUTPUT := lib$(NAME).so ifeq ($(DEBUG), 1) GODEBUGFLAGS= GODEBUG=cgocheck=2 else GODEBUGFLAGS= GODEBUG=cgocheck=0 endif all: build clean: @rm -f lib$(NAME).so build: clean @$(GODEBUGFLAGS) $(GO) build -buildmode=c-shared -buildvcs=false -o $(OUTPUT) ./plugin With PLUGIN_NAME as the name of your plugin.\nYou can test it by running make build and see the lib{PLUGIN_NAME}.so appearing at the root of your folder.\nGithub Actions Workflow The first step is to create the .github/workflows folder and the release.yaml file describing our workflow.\nHeaders Each workflow starts with, at least, a name and a on:\nname: Release Plugins on: push: tags: - \u0026#39;[0-9]+\\.[0-9]+\\.[0-9]+\u0026#39; env: OCI_REGISTRY: ghcr.io PLUGIN_NAME: {PLUGIN_NAME} permissions: contents: write packages: write The workflow will be triggered each time a tag following semantic versioning (major.minor.patch) is created.\nOnce again PLUGIN_NAME is the name of your plugin, it will be set as env var to be reused all over the file. It's the only thing to adapt to your context. We also set the registry (Github Packages) URL with OCI_REGISTRY.\nThe permissions are required to allow Github Actions to read the content of your repo, create the release and push the artifacts into Github Packages.\nThe jobs Once we have set the \u0026quot;headers\u0026quot; of the workflow file, it's time to set the actions that will be run. We'll split them into 2:\nPublish the OCI artifacts Create the release Publish the OCI artifacts To publish the artifacts, we'll use falcoctl, the official CLI to manage Falco artifacts.\nThe steps to publishing the artifacts will be, in this order:\nGet the falcoctl sources Prepare the Go env Build falcoctl (guarantees the latest version) Get the plugin sources Build the plugin (.so file) Get the repo name in lower case Push the artifacts with all their tags: push the plugin push the rules with a dependency to the plugin jobs: publish-oci-artifacts: runs-on: ubuntu-latest steps: - name: Checkout Falcoctl Repo uses: actions/checkout@v3 with: repository: falcosecurity/falcoctl ref: main path: tools/falcoctl - name: Setup Golang uses: actions/setup-go@v4 with: go-version: \u0026#39;^1.20\u0026#39; cache-dependency-path: tools/falcoctl/go.sum - name: Build falcoctl run: make working-directory: tools/falcoctl - name: Checkout uses: actions/checkout@v3 with: path: plugin - name: Build the plugin run: make build working-directory: plugin - id: StringRepoName uses: ASzc/change-string-case-action@v5 with: string: ${{ github.repository }} - name: Upload OCI artifacts to GitHub packages run: | MAJOR=$(echo ${{ github.ref_name }} | cut -f1 -d\u0026#34;.\u0026#34;) MINOR=$(echo ${{ github.ref_name }} | cut -f1,2 -d\u0026#34;.\u0026#34;) DIR=$(pwd) cd plugin/ $DIR/tools/falcoctl/falcoctl registry push \\ ${{ env.OCI_REGISTRY }}/${{ steps.StringRepoName.outputs.lowercase }}/plugin/${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --config /dev/null \\ --type plugin \\ --version \u0026#34;${{ github.ref_name }}\u0026#34; \\ --tag latest --tag $MAJOR --tag $MINOR \\ --platform linux/amd64 \\ --requires plugin_api_version:2.0.0 \\ --depends-on ${{ env.PLUGIN_NAME }}-rules:${{ github.ref_name }} \\ --name ${{ env.PLUGIN_NAME }} \\ lib${{ env.PLUGIN_NAME }}.so cd rules/ $DIR/tools/falcoctl/falcoctl registry push \\ ${{ env.OCI_REGISTRY }}/${{ steps.StringRepoName.outputs.lowercase }}/ruleset/${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --config /dev/null \\ --type rulesfile \\ --version \u0026#34;${{ github.ref_name }}\u0026#34; \\ --tag latest --tag $MAJOR --tag $MINOR \\ --depends-on ${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --name ${{ env.PLUGIN_NAME }}-rules \\ ${{ env.PLUGIN_NAME }}_rules.yaml env: FALCOCTL_REGISTRY_AUTH_BASIC: ${{ env.OCI_REGISTRY }},${{ github.repository_owner }},${{ secrets.GITHUB_TOKEN }} Create the release GoReleaser can automatically generate a Changelog at the same time we publish the new artifacts. This step isn't imperative to generate the OCI artifacts but it's a good practice among Go developers. To achieve that, make sure to have a correct .goreleaser.yml file as explained here.\nrelease: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Setup Golang uses: actions/setup-go@v3 with: go-version: \u0026#39;1.19\u0026#39; - name: Run GoReleaser uses: goreleaser/goreleaser-action@v4 with: version: latest args: release --clean --timeout 120m env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} LDFLAGS: \u0026#34;-buildmode=c-shared\u0026#34; GOPATH: /home/runner/go Final result name: Release Plugins on: push: tags: - \u0026#39;[0-9]+\\.[0-9]+\\.[0-9]+\u0026#39; env: OCI_REGISTRY: ghcr.io PLUGIN_NAME: {PLUGIN_NAME} permissions: contents: write packages: write jobs: publish-oci-artifacts: runs-on: ubuntu-latest steps: - name: Checkout Falcoctl Repo uses: actions/checkout@v3 with: repository: falcosecurity/falcoctl ref: 0.5.0 # adapt to the latest version path: tools/falcoctl - name: Setup Golang uses: actions/setup-go@v4 with: go-version: \u0026#39;^1.20\u0026#39; cache-dependency-path: tools/falcoctl/go.sum - name: Build falcoctl run: make working-directory: tools/falcoctl - name: Checkout uses: actions/checkout@v3 with: path: plugin - name: Build the plugin run: make build working-directory: plugin - id: StringRepoName uses: ASzc/change-string-case-action@v5 with: string: ${{ github.repository }} - name: Upload OCI artifacts to GitHub packages run: | MAJOR=$(echo ${{ github.ref_name }} | cut -f1 -d\u0026#34;.\u0026#34;) MINOR=$(echo ${{ github.ref_name }} | cut -f1,2 -d\u0026#34;.\u0026#34;) DIR=$(pwd) cd plugin/ $DIR/tools/falcoctl/falcoctl registry push \\ ${{ env.OCI_REGISTRY }}/${{ steps.StringRepoName.outputs.lowercase }}/plugin/${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --config /dev/null \\ --type plugin \\ --version \u0026#34;${{ github.ref_name }}\u0026#34; \\ --tag latest --tag $MAJOR --tag $MINOR \\ --platform linux/amd64 \\ --requires plugin_api_version:2.0.0 \\ --depends-on ${{ env.PLUGIN_NAME }}-rules:${{ github.ref_name }} \\ --name ${{ env.PLUGIN_NAME }} \\ lib${{ env.PLUGIN_NAME }}.so cd rules/ $DIR/tools/falcoctl/falcoctl registry push \\ ${{ env.OCI_REGISTRY }}/${{ steps.StringRepoName.outputs.lowercase }}/ruleset/${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --config /dev/null \\ --type rulesfile \\ --version \u0026#34;${{ github.ref_name }}\u0026#34; \\ --tag latest --tag $MAJOR --tag $MINOR \\ --depends-on ${{ env.PLUGIN_NAME }}:${{ github.ref_name }} \\ --name ${{ env.PLUGIN_NAME }}-rules \\ ${{ env.PLUGIN_NAME }}_rules.yaml env: FALCOCTL_REGISTRY_AUTH_BASIC: ${{ env.OCI_REGISTRY }},${{ github.repository_owner }},${{ secrets.GITHUB_TOKEN }} release: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Setup Golang uses: actions/setup-go@v3 with: go-version: \u0026#39;1.19\u0026#39; - name: Run GoReleaser uses: goreleaser/goreleaser-action@v4 with: version: latest args: release --clean --timeout 120m env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} LDFLAGS: \u0026#34;-buildmode=c-shared\u0026#34; GOPATH: /home/runner/go Replace PLUGIN_NAME with the name of your plugin.\nThe index.yaml file for falcoctl This file is used by falcoctl to know where to download your plugin and rules. Please read this blog post to understand better how it works.\nWe'll create our own file to allow like the following:\n- name: {PLUGIN_NAME} type: plugin registry: ghcr.io repository: {OWNER_NAME}/{REPO_NAME}/plugin/{PLUGIN_NAME} description: {DESCRIPTION} home: https://github.com/{OWNER_NAME}/{PLUGIN_NAME} keywords: - {PLUGIN_NAME} license: Apache-2.0 maintainers: - email: {OWNER_EMAIL} name: {OWNER_REAL_NAME} sources: - https://github.com/{OWNER_NAME}/{PLUGIN_NAME} - name: {PLUGIN_NAME}-rules type: rulesfile registry: ghcr.io repository: {OWNER_NAME}/{REPO_NAME}/ruleset/docker description: Rules for the {PLUGIN_NAME} plugin home: https://github.com/{OWNER_NAME}/{REPO_NAME}/tree/main/rules keywords: - {PLUGIN_NAME} license: Apache-2.0 maintainers: - email: {OWNER_EMAIL} name: {OWNER_REAL_NAME} sources: - https://github.com/{OWNER_NAME}/{REPO_NAME}/tree/main/rules/{PLUGIN_NAME}_rules.yaml With:\nPLUGIN_NAME: the name of you plugin OWNER_NAME: your nickname on Github REPO_NAME: the name of your repo for your plugin on Github OWNER_EMAIL: an email for contact OWNER_REAL_NAME: your real name or not DESCRIPTION: description of your plugin falcoctl uses the keywords field to perform a search among your plugins. Leverage this functionality by adding relevant terms to your plugin.\nThe repository structure should look like the following:\n├── .github │ └── workflows │ └── release.yaml ├── .gitignore ├── go.mod ├── .goreleaser.yml ├── go.sum ├── index.yaml ├── LICENSE ├── Makefile ├── README.md ├── pkg │ └── {PLUGIN_NAME}.go ├── plugin │ └── main.go └── rules └── {PLUGIN_NAME}_rules.yaml There are 2 ways to expose the index.yaml file:\nexposing the raw file: https://raw.githubusercontent.com/{OWNER_NAME}/{REPO_NAME}/main/index.yaml exposing the file through Github Page: https://{OWNER_NAME}.github.io/{REPO_NAME}/index.yaml (make sure to enable the Pages) Create our first version Everything is now ready to publish a first version of our plugin.\nIn the main branch, run:\ngit tag 0.1.0 -m \u0026#34;0.1.0\u0026#34; \u0026amp;\u0026amp; git push origin 0.1.0 Few seconds after, your workflow should be started and you will have your first published version with associated artifacts.\nInstallation of your plugin and rules The process is now the same as the one described here, except we'll use your specific index.yaml to register a new index:\nsudo falcoctl index add {PLUGIN_NAME} https://{OWNER_NAME}.github.io/{REPO_NAME}/index.yaml sudo falcoctl artifact install {PLUGIN_NAME} sudo falcoctl artifact install {PLUGIN_NAME}-rules For the docker plugin, for example:\n❯ sudo falcoctl index add docker http://issif.github.io/docker-plugin/index.yaml ❯ sudo falcoctl artifact search docker INDEX ARTIFACT TYPE REGISTRY\tREPOSITORY docker\tdocker plugin ghcr.io issif/docker-plugin/plugin/docker docker\tdocker-rules\trulesfile\tghcr.io issif/docker-plugin/ruleset/docker ❯ sudo falcoctl artifact install docker-rules INFO Reading all configured index files from \u0026#34;/root/.config/falcoctl/indexes.yaml\u0026#34; INFO Resolving dependencies ... INFO Installing the following artifacts: [docker:0.3.3 ghcr.io/issif/docker-plugin/ruleset/docker:latest] INFO Preparing to pull \u0026#34;ghcr.io/issif/docker-plugin/plugin/docker:0.3.3\u0026#34; INFO Pulling 9145239be00e: ############################################# 100% INFO Pulling 2073e106ba07: ############################################# 100% INFO Pulling 01ecf22a3821: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/usr/share/falco/plugins\u0026#34; INFO Preparing to pull \u0026#34;ghcr.io/issif/docker-plugin/ruleset/docker:latest\u0026#34; INFO Pulling 3482c7ca931f: ############################################# 100% INFO Pulling 433ad24cb056: ############################################# 100% INFO Pulling e449b880035d: ############################################# 100% INFO Artifact successfully installed in \u0026#34;/etc/falco\u0026#34; ","summary":"","tags":null,"title":"How to distribute a plugin","url":"https://v0-43--falcosecurity.netlify.app/docs/developer-guide/plugins/how-to-distribute/"},{"category":"docs","content":" Falco consumes streams of events and evaluates them against a set of security rules to detect abnormal behavior. By default, Falco is pre-configured to consume events from the Linux Kernel. This scenario requires Falco to be privileged, and depending on the kernel version installed on the node, a driver will be installed on the node. Since orchestration systems like Kubernetes are out of scope for this section, it's up to the user to manage the container lifecycle and deployment across the nodes.\nFor other installation scenarios, such as consuming cloud events or other data sources using plugins, please refer to the Plugins section.\nInstall This section describes how to run the Falco userspace process in a container using one of the released container images.\nBy default, Falco is pre-configured to consume events from the Linux Kernel. For this default installation scenario, Falco can be run in two ways:\nFully Privileged Least Privileged (Recommended) Different instructions apply to each method depending on the driver used. Note that the Modern eBPF does not require driver installation.\nFully Privileged To run Falco in a container using Docker with full privileges, use the following commands:\nModern eBPF The Modern eBPF is bundled into the Falco binary. This allows you to run Falco without dependencies by using the following command:\ndocker pull falcosecurity/falco:0.43.0 docker run --rm -it \\ --privileged \\ -v /sys/kernel/tracing:/sys/kernel/tracing:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /proc:/host/proc:ro \\ -v /etc:/host/etc:ro \\ falcosecurity/falco:0.43.0 On some systems, tracefs is available at /sys/kernel/debug/tracing instead of /sys/kernel/tracing. If this is the case, please replace -v /sys/kernel/tracing:/sys/kernel/tracing:ro with -v /sys/kernel/debug/tracing:/sys/kernel/tracing:ro.\nMounting the host's tracefs (i.e.: mounting the host /sys/kernel/tracing path) is an optional but recommended pre-requisite. By removing the -v /sys/kernel/tracing:/sys/kernel/tracing:ro line from the above command, you will reduce the amount of accesses granted to the container, but will not benefit anymore from TOCTOU mitigation support.\nKernel Module For the Kernel Module driver, Falco requires the driver to be installed on the host system first.\nInstall the driver on the host system using the falcosecurity/falco-driver-loader image, as described in the Driver Installation section.\nRun Falco:\ndocker pull falcosecurity/falco:0.43.0 docker run --rm -it \\ --privileged \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /etc:/host/etc:ro \\ falcosecurity/falco:0.43.0 falco -o engine.kind=kmod eBPF Probe For the eBPF probe driver, Falco requires the probe to be prepared and stored on the host system first (under /root/.falco).\nInstall the driver on the host system using the falcosecurity/falco-driver-loader image, as described in the Driver Installation section.\nRun Falco:\ndocker pull falcosecurity/falco:0.43.0 docker run --rm -it \\ --privileged \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /root/.falco:/root/.falco \\ -v /proc:/host/proc:ro \\ -v /etc:/host/etc:ro \\ falcosecurity/falco:0.43.0 falco -o engine.kind=ebpf # If running a kernel version \u0026lt; 4.14, add \u0026#39;-v /sys/kernel/debug:/sys/kernel/debug:ro \\\u0026#39; to the above docker command. Least Privileged (Recommended) To run Falco in a container using Docker with the principle of least privilege, you can use the following commands depending on the driver you want to use.\nModern eBPF docker pull falcosecurity/falco:0.43.0 docker run --rm -it \\ --cap-drop all \\ --cap-add sys_admin \\ --cap-add sys_resource \\ --cap-add sys_ptrace \\ -v /sys/kernel/tracing:/sys/kernel/tracing:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /proc:/host/proc:ro \\ -v /etc:/host/etc:ro \\ falcosecurity/falco:0.43.0 The minimum set of capabilities to run Falco with the Modern eBPF driver are:\nCAP_SYS_PTRACE CAP_SYS_RESOURCE CAP_BPF CAP_PERFMON However, in the command above, we use CAP_SYS_ADMIN because Docker does not yet support CAP_BPF and CAP_PERFMON.\nOn some systems, tracefs is available at /sys/kernel/debug/tracing instead of /sys/kernel/tracing. If this is the case, please replace -v /sys/kernel/tracing:/sys/kernel/tracing:ro with -v /sys/kernel/debug/tracing:/sys/kernel/tracing:ro.\nMounting the host's tracefs (i.e.: mounting the host /sys/kernel/tracing path) is an optional but recommended pre-requisite. By removing the -v /sys/kernel/tracing:/sys/kernel/tracing:ro line from the above command, you will reduce the amount of accesses granted to the container, but will not benefit anymore from TOCTOU mitigation support.\nKernel Module For the Kernel Module driver, Falco requires the driver to be installed on the host system first. This step requires full privileges, while the Falco container can then run with the least privileges.\nInstall the driver on the host system using the falcosecurity/falco-driver-loader image, as described in the Driver Installation section.\nRun Falco using the falcosecurity/falco image with the least privileges:\ndocker pull falcosecurity/falco:0.43.0 docker run --rm -it \\ -e HOST_ROOT=/ \\ --cap-add SYS_PTRACE --pid=host $(ls /dev/falco* | xargs -I {} echo --device {}) \\ -v /var/run/docker.sock:/var/run/docker.sock \\ -v /etc:/host/etc:ro \\ falcosecurity/falco:0.43.0 falco -o engine.kind=kmod Note that ls /dev/falco* | xargs -I {} echo --device {} outputs a --device /dev/falcoX option per CPU (i.e., just the devices created by the Falco's kernel module). Also, -e HOST_ROOT=/ is necessary since with --device there is no way to remap devices to /host/dev/.\nIf you are running Falco on a system with the AppArmor LSM enabled (e.g., Ubuntu), you must also pass --security-opt apparmor:unconfined to the docker run command above.\nYou can verify if you have AppArmor enabled using the command below:\ndocker info | grep -i apparmor eBPF Probe For the eBPF probe driver, Falco requires the probe to be prepared and stored on the host system first (under /root/.falco). This step requires full privileges, after which the Falco container can run with the least privileges.\nInstall the driver on the host system using the falcosecurity/falco-driver-loader image, as described in the Driver Installation section.\nRun Falco using the falcosecurity/falco image with the least privileges:\ndocker pull falcosecurity/falco:0.43.0 docker run --rm -it \\ --cap-drop all \\ --cap-add sys_admin \\ --cap-add sys_resource \\ --cap-add sys_ptrace \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /root/.falco:/root/.falco \\ -v /proc:/host/proc:ro \\ -v /etc:/host/etc \\ falcosecurity/falco:0.43.0 falco -o engine.kind=ebpf # If running a kernel version \u0026lt; 4.14, add \u0026#39;-v /sys/kernel/debug:/sys/kernel/debug:ro \\\u0026#39; to the above Docker command. If you are running Falco on a system with the AppArmor LSM enabled (e.g., Ubuntu), you must also pass --security-opt apparmor:unconfined to the docker run command above.\nTo verify if AppArmor is enabled, use the command below:\ndocker info | grep -i apparmor To run Falco with the least privileges using the eBPF probe, the following capabilities are required:\nOn kernels \u0026lt;5.8, Falco requires CAP_SYS_ADMIN, CAP_SYS_RESOURCE, and CAP_SYS_PTRACE. On kernels \u0026gt;=5.8, CAP_BPF and CAP_PERFMON were separated from CAP_SYS_ADMIN, so the required capabilities are CAP_BPF, CAP_PERFMON, CAP_SYS_RESOURCE, CAP_SYS_PTRACE. Unfortunately, Docker does not yet support adding the two newly introduced capabilities with the --cap-add option. For this reason, we continue using CAP_SYS_ADMIN, which still allows performing the same operations granted by CAP_BPF and CAP_PERFMON. In the near future, Docker will support adding these two capabilities, and we will be able to replace CAP_SYS_ADMIN. Driver Installation This section provides instructions for installing the driver on the host system using the falcosecurity/falco-driver-loader image. This approach is helpful if you prefer to install the driver on the host first and then run Falco in a container later.\nDriver installation on the host is only required for the Kernel Module and eBPF probe drivers.\nYou can skip this section if you plan to use the Modern eBPF.\nWhen using the eBPF probe or kernel module drivers, the driver loader attempts to either download a prebuilt driver or build it on the fly as a fallback. Starting with Falco 0.38, the driver loader has improved functionality to automatically retrieve the required kernel headers for distributions supported by driverkit. This enhancement ensures that the necessary kernel headers are available to dynamically build the appropriate driver—whether it is the Kernel Module or the eBPF probe.\nHowever, if the driver loader cannot automatically fetch the required kernel headers, you may need to install them manually on the host as a prerequisite. For detailed instructions on manual installation, refer to the Installation section.\nThe falcosecurity/falco-driver-loader:0.43.0 is based on a recent Debian image. For ancient kernel versions, this might not work. The alternative falcosecurity/falco-driver-loader:0.43.0-buster (based on an older Debian image) may work in such a case.\nKernel Module To install the kernel module driver on the host system, you can use the following command:\ndocker pull falcosecurity/falco-driver-loader:0.43.0 docker run --rm -it \\ --privileged \\ -v /root/.falco:/root/.falco \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules \\ -v /usr:/host/usr:ro \\ -v /proc:/host/proc:ro \\ -v /etc:/host/etc:ro \\ falcosecurity/falco-driver-loader:0.43.0 kmod eBPF Probe To install the eBPF probe driver on the host system, you can use the following command:\ndocker pull falcosecurity/falco-driver-loader:0.43.0 docker run --rm -it \\ --privileged \\ -v /root/.falco:/root/.falco \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ -v /proc:/host/proc:ro \\ -v /etc:/host/etc:ro \\ falcosecurity/falco-driver-loader:0.43.0 ebpf Verify Image Signing All official container images for Falco, starting from version 0.35.0, are signed with cosign. To verify the signature, you can run the following command:\ncosign verify docker.io/falcosecurity/falco:0.43.0 \\ --certificate-oidc-issuer=https://token.actions.githubusercontent.com \\ --certificate-identity-regexp=https://github.com/falcosecurity/falco/ \\ --certificate-github-workflow-ref=refs/tags/0.43.0 Replace docker.io/falcosecurity/falco with any official Falco image (falco, falco-driver-loader) from any official container registry to verify other images.\nIf you have your own container registry and wish to retain the signature while copying Falco images, you can simply use the cosign copy command:\ncosign copy docker.io/falcosecurity/falco:0.43.0 your-registry/falco:0.43.0 And you'll be able to easily verify that the image in your registry was not tampered with!\nConfiguration You can configure Falco by either:\nPassing the -o command line flag to the Docker run command Or by mounting a custom configuration file into the container (e.g., -v /path/to/falco.yaml:/etc/falco/falco.yaml) Further configurable options via environment variables include (to be passed with -e with Docker):\nFALCOCTL_DRIVER_REPOS - See the Installing the Driver section. SKIP_DRIVER_LOADER - Set this environment variable to avoid running falcoctl driver tool when the falcosecurity/falco image starts. Useful when the driver has already been installed on the host by other means. ","summary":"","tags":null,"title":"Deploy as a container","url":"https://v0-43--falcosecurity.netlify.app/docs/setup/container/"},{"category":"docs","content":"The default Falco rule set defines a number of macros that makes it easier to start writing rules. These macros provide shortcuts for a number of common scenarios and can be used in any user defined rule sets.\nFalco also provide Macros that should be overridden. Refer here for further information.\nFile Opened for Writing \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;open_write\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: (evt.type=open or evt.type=openat) and evt.is_open_write=true and fd.typechar='f' and fd.num\u0026gt;=0 File Opened for Reading \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;open_read\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: (evt.type=open or evt.type=openat) and evt.is_open_read=true and fd.typechar='f' and fd.num\u0026gt;=0 Never True \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;never_true\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: (evt.num=0) Always True \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;always_true\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: (evt.num=\u0026gt;0) Proc Name is Set \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;proc_name_exists\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: (proc.name!=\u0026quot;\u0026lt;NA\u0026gt;\u0026quot;) File System Object Renamed \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;rename\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: evt.type in (rename, renameat) New Directory Created \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;mkdir\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: evt.type = mkdir File System Object Removed \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;remove\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: evt.type in (rmdir, unlink, unlinkat) File System Object Modified \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;modify\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: rename or remove New Process Spawned \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;spawned_process\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: (evt.type in (execve, execveat)) Common Directories for Binaries \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;bin_dir\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: fd.directory in (/bin, /sbin, /usr/bin, /usr/sbin) Shell is Started \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;shell_procs\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: (proc.name in (shell_binaries)) Known Sensitive Files \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;sensitive_files\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: \u0026gt; fd.name startswith /etc and (fd.name in (sensitive_file_names) or fd.directory in (/etc/sudoers.d, /etc/pam.d)) Newly Created Process \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;proc_is_new\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: proc.duration \u0026lt;= 5000000000 Inbound Network Connections \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;inbound\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: \u0026gt; ((evt.type in (accept,listen)) or (fd.typechar = 4 or fd.typechar = 6) and (fd.ip != \u0026quot;0.0.0.0\u0026quot; and fd.net != \u0026quot;127.0.0.0/8\u0026quot;) and (evt.rawres \u0026gt;= 0 or evt.res = EINPROGRESS)) Outbound Network Connections \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;outbound\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: \u0026gt; ((evt.type = connect) or (fd.typechar = 4 or fd.typechar = 6) and (fd.ip != \u0026quot;0.0.0.0\u0026quot; and fd.net != \u0026quot;127.0.0.0/8\u0026quot;) and (evt.rawres \u0026gt;= 0 or evt.res = EINPROGRESS)) Inbound or Outbound Network Connections \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;inbound_outbound\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: \u0026gt; ((evt.type in (accept,listen,connect)) or (fd.typechar = 4 or fd.typechar = 6) and (fd.ip != \u0026quot;0.0.0.0\u0026quot; and fd.net != \u0026quot;127.0.0.0/8\u0026quot;) and (evt.rawres \u0026gt;= 0 or evt.res = EINPROGRESS)) Object is a Container \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;container\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: container.id != host Interactive Process Spawned \u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-yaml\u0026quot; data-lang=\u0026quot;yaml\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;- \u0026lt;span style=\u0026quot;color:#008000;font-weight:bold\u0026quot;\u0026gt;macro\u0026lt;/span\u0026gt;:\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; \u0026lt;/span\u0026gt;interactive\u0026lt;span style=\u0026quot;color:#bbb\u0026quot;\u0026gt; condition: \u0026gt; ((proc.aname=sshd and proc.name != sshd) or proc.name=systemd-logind or proc.name=login) ","summary":"","tags":null,"title":"Default Macros","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/rules/default-macros/"},{"category":"docs","content":"Falco comes with a default rules file that is loaded if no specific configuration is provided. However, that can be completely customized in several ways, depending on how Falco is installed. There are several ways to specify the location of your custom rules, download them, and keep them up to date.\nThe configuration file The default configuration file, /etc/falco/falco.yaml makes Falco load rules from the /etc/falco/falco_rules.yaml file, followed by any custom rules located in the /etc/falco/falco_rules.local.yaml file, followed by any custom rules located in the /etc/falco/rules.d directory. This configuration is governed by the rules_files key:\nrules_files: - /etc/falco/falco_rules.yaml - /etc/falco/falco_rules.local.yaml - /etc/falco/rules.d Changing these configuration entries will affect the location and loading order of the rules files.\nYou can find the details of the available default rules in this page or in the Falco rules auto-generated documentation.\nIf you are running Falco directly from the command line, you can use the -r switch to load as many rules files as needed. Is it possible to provide -r with the path of a single file or directory (in this latter case, all the rules files in the directory will be loaded). The switch can be specified multiple times; if is specified at least once, the rules_files key in the configuration file is ignored. e.g.:\n# falco -r /path/to/my/rules1.yaml -r /path/to/my/rules2.yaml Falcoctl The falcoctl tool provides functionality to download and update rules files distributed as OCI artifacts. The install command of the falcoctl tool will download rules files to a configurable directory (by default, that is /etc/falco). For instance, to install a specific version of the default rules file in /etc/falco you can run the following commands:\n# falcoctl index add falcosecurity https://falcosecurity.github.io/falcoctl/index.yaml # falcoctl artifact install falco-rules:3.2.0 Falcoctl is available as a standalone tool, included in Falco packages and container images, automatically installed as a systemd unit or deployed as an init container via the Helm chart.\nRules installed via the Helm chart If you install the Helm chart, at least version 3.0.0 with:\nhelm install falco Falco, by default, will load the latest rules file that is compatible with your Falco version and keep it up to date automatically via falcoctl. These are published on GitHub Packages.\nUse the rules embedded in the Falco image The Falco image ships with a snapshot of the latest version of the official Falco rules. If you wish to use that without downloading anything at runtime, you can install Falco with:\nhelm install falco \\ --set falcoctl.artifact.install.enabled=false \\ --set falcoctl.artifact.follow.enabled=false Add custom rules with a configmap You can always use the customRules value to add your own custom rules in a configmap. For instance, if we create a file as described in the documentation, and then add it to our install command above as follows:\nhelm install falco \\ --set falcoctl.artifact.install.enabled=false \\ --set falcoctl.artifact.follow.enabled=false \\ -f custom_rules.yaml or if you have already installed falco, you can use the helm upgrade -i\nhelm upgrade -i falco \\ --set falcoctl.artifact.install.enabled=false \\ --set falcoctl.artifact.follow.enabled=false \\ -f custom_rules.yaml it will be loaded and configured in our Falco instance and you can verify changes by checking the falco daemonset container logs with the command below:\nkubectl logs -n falco daemonsets/falco Notice: the new rule files described in customRules will be placed in the /etc/falco/rules.d directory, and will be loaded following the order specified in the configuration file: in the default configuration, this means that will be loaded after /etc/falco/falco.yaml and /etc/falco/falco_rules.local.yaml rules files.\nOnly use rules supplied via configmap If you only want to use the rules that you add via configmap, discarding all automated updates and default rules shipped in the image, you have to remove the falco_rules.yaml and falco_rules.local.yaml entries from the Falco configuration. Assuming you have your custom rules in custom_rules.yaml:\nhelm install falco -f ./custom_rules.yaml \\ --set \u0026#34;falco.rules_files={/etc/falco/rules.d}\u0026#34; \\ --set falcoctl.artifact.install.enabled=false \\ --set falcoctl.artifact.follow.enabled=false ","summary":"","tags":null,"title":"Default and Local Rules Files","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/default-custom/"},{"category":"docs","content":"Introduction This page documents the functions that make up the Falco plugins API. In most cases, you will not need to implement these functions directly. There are Go and C++ SDKs that provide an easier-to-use interface for plugin authors.\nAt a high level, the API functions are grouped as follows:\nFunctions that are commons to all plugins Functions that implement one specific capability The C header files plugin_api.h numerate all the API functions and associated structs/types as they are used by the plugins framework. The whole plugin API and the loader used in Falco are implemented in C in a standalone module located inside falcosecurity/libs/userspace/plugin, and can be imported and reused in other projects using the falcosecurity plugin system (e.g. we have a plugin loader written in Go developed on top of the C one).\nRemember, however, that from the perspective of the plugin, each function name has a prefix plugin_ e.g. plugin_get_required_api_version, plugin_get_name, etc.\nSince Falco v0.33.0, some function symbols of the plugin API started supporting concurrent invocations from multiple threads. If not explicitly specified in each symbol's API reference, the plugin API assumes that functions are invoked always from the same thread with no concurrency.\nPlugin API Versioning The current version of the plugin API is 3.6.0.\nThe plugin API is a formal contract between the framework and the plugins, and it is versioned using semantic versioning. The framework exposes the plugin API version it supports, and each plugin expresses a required plugin API version. If the version required by a plugin does not pass the semantic check with the one supported by the framework, then the plugin cannot be loaded. See the section about plugin_get_required_api_version for more details.\nConventions The following conventions apply for all of the below API functions:\nEvery function that returns a const char* must return a null-terminated C string. All string values returned across the API are considered owned by the plugin and must remain valid for use by the plugin framework. Specifically, this means: For demographic functions like plugin_get_name, plugin_get_description, the returned strings must remain valid until the plugin is destroyed. When returning events via plugin_next_batch, both the array of structs and the data payloads inside each struct must remain valid until the next call to plugin_next_batch. When returning extracted string values via plugin_extract_fields, every extracted string must remain valid until the next call to plugin_extract_fields. For every function that returns an error, the plugin should save a meaningful error string that the framework can retrieve via a call to plugin_get_last_error. Inversion of Control and Callbacks to the Plugin's Owner All functions from the plugin API define functionalities that the plugin offers to the framework. In the default execution path, the plugin is always the \u0026quot;passive\u0026quot; actor, with the framework being the orchestrator determining when and how often a given plugin function gets invoked.\nThe plugin API also supports an occasional inversion of control in which plugins can actively invoke functions exposed by the framework that owns it. For those cases, the execution flow generally proceeds as follows. First, the framework invokes a function exported by the plugin according its supported version of the plugin API. As one of the function arguments the framework passes to the plugin a vtable struct allocated and owned by the framework itself, containing one or more function pointers referring to code functions of the framework that the plugin is allowed to invoke. Permissions about retaining such function pointers inside the plugin's state after the execution of the plugin API symbol may vary depending on the API symbol itself and its related capabilities. Alongside the function pointers, the framework also provides the plugin with a ss_plugin_owner_t* opaque handle, which the plugin must pass to the framework's functions. The opaque handle represents an instance of the plugin's owner, which is an abstract component that the framework allocates for managing the plugin's requests. If the framework passes one of the function pointers defined in the vtable structs as NULL, then the plugin must assume that the related piece of functionality is not supported by the framework in that context. Plugins must always check whether the function pointers passed by the framework are NULL or not.\nAn example of functionality provided in the form of inversion of control is the access to state tables. The C++ example below shows how a plugin can interact with its owner during the execution of its init function. In this case, the plugin iterates over the list of state tables registered in the framework and catches errors arising during the invocations of the owner's callbacks:\nextern \u0026#34;C\u0026#34; ss_plugin_t* plugin_init(const ss_plugin_init_input* in, ss_plugin_rc* rc) { *rc = SS_PLUGIN_SUCCESS; my_plugin *ret = new my_plugin(); if (!in || !in-\u0026gt;tables) { *rc = SS_PLUGIN_FAILURE; ret-\u0026gt;lasterr = \u0026#34;access to the state tables is not supported by the owner\u0026#34;; return ret; } uint32_t ntables = 0; auto tables = in-\u0026gt;tables-\u0026gt;list_tables(in-\u0026gt;owner, \u0026amp;ntables); if (!tables) { *rc = SS_PLUGIN_FAILURE; ret-\u0026gt;lasterr = \u0026#34;can\u0026#39;t list state tables: \u0026#34; + std::string(in-\u0026gt;get_owner_last_error(in-\u0026gt;owner)); return ret; } for (uint32_t i = 0; i \u0026lt; ntables; i++) { auto\u0026amp; ti = tables[i]; printf(\u0026#34;table=\u0026#39;%s\u0026#39;, key_type=%d\\n\u0026#34;, ti.name, ti.key_type); } return ret; } Logging Another functionality that makes use of inversion of control is logging.\nThe framework provides a log function during the plugin initialization, which the plugin can use to invoke the framework-provided logger at any time during the plugin life-cycle.\nThe following C++ example shows how a plugin can retain the owner's handle and the log function to invert control and invoke the framework logger:\nstruct my_plugin { ss_plugin_owner_t* owner; ss_plugin_log_fn_t log; }; extern \u0026#34;C\u0026#34; ss_plugin_t* plugin_init(const ss_plugin_init_input* in, ss_plugin_rc* rc) { *rc = SS_PLUGIN_SUCCESS; my_plugin *ret = new my_plugin(); ret-\u0026gt;log = in-\u0026gt;log_fn; ret-\u0026gt;owner = in-\u0026gt;owner; ret-\u0026gt;log(ret-\u0026gt;owner, NULL, \u0026#34;initializing plugin...\u0026#34;, SS_PLUGIN_LOG_SEV_INFO); return ret; } extern \u0026#34;C\u0026#34; void plugin_destroy(ss_plugin_t* s) { my_plugin *ps = (my_plugin *) s; ps-\u0026gt;log(ps-\u0026gt;owner, NULL, \u0026#34;destroying plugin...\u0026#34;, SS_PLUGIN_LOG_SEV_INFO); delete ((my_plugin *) s); } The signature of the log function is:\nvoid log(ss_plugin_owner_t* owner, const char* component, const char* msg, ss_plugin_log_severity sev); where owner is the handle of the owner, component is a string representing the plugin's component name that is invoking the logger (falls back to the plugin name when NULL), msg is the log message and sev is the log severity as defined in API.\nCommon Plugin API get_required_api_version const char* plugin_get_required_api_version() [Required: yes] This function returns a string containing a semver version number e.g. \u0026quot;3.0.0\u0026quot;, reflecting the version of the plugin API framework that this plugin requires. This is different than the version of the plugin itself, and should only have to change when the plugin API changes.\nThis is the first function the framework calls when loading a plugin. If the returned value is not semver-compatible with the version of the plugin API framework, the plugin will not be loaded.\nFor example, if the code implementing the plugin framework has version 1.1.0, and a plugin's plugin_get_required_api_version function returns 1.0.0, the plugin API is compatible and the plugin will be loaded. If the code implementing the plugin framework has version 3.0.0, and a plugin's plugin_get_required_api_version function returns 1.0.0, the API is not compatible and the plugin will not be loaded.\nget_{name,description,contact,version} const char* plugin_get_name() [Required: yes] const char* plugin_get_description() [Required: yes] const char* plugin_get_contact() [Required: yes] const char* plugin_get_version() [Required: yes] These functions all return an C string, with memory owned by the plugin, that describe the plugin:\nplugin_get_name: Return the name of the plugin. plugin_get_description: Return a short description of the plugin. plugin_get_contact: Return a contact url/email/twitter account for the plugin authors. plugin_get_version: Return the version of the plugin itself. For get_version, note that increasing the major version signals breaking changes in the plugin implementation but must not change the serialization format of the event data. For example, events written in pre-existing capture files must always be readable by newer versions of the plugin.\ninit ss_plugin_t* plugin_init(const ss_plugin_init_input *input, ss_plugin_rc *rc) [Required: yes] This function passes plugin-level configuration to the plugin to create its plugin-level state. The plugin then returns a pointer to that state, as a ss_plugin_t * handle. The handle is never examined by the plugin framework and is never freed. It is only provided as the argument to later API functions.\nWhen managing plugin-level state, keep the following in mind:\nIt is the plugin's responsibility to allocate plugin state (memory, open files, etc) and free that state later in plugin_destroy. The plugin state should be the only location for state (e.g. no globals, no per-thread state). Although unlikely, the framework may choose to call plugin_init multiple times for the same plugin, and this should be supported by the plugin. The returned rc value should be SS_PLUGIN_SUCCESS (0) on success, SS_PLUGIN_FAILURE (1) on failure. On failure, make sure to return a meaningful error message in the next call to plugin_get_last_error. On failure, plugins can decide whether to return an allocated state or not. In the first case, the plugin framework will use the allocated state to retrieve the failure error with plugin_get_last_error, and will then free the state with plugin_destroy. In the second case, plugin_destroy will not be called and the plugin framework will return a generic error. The format of the config string is entirely determined by the plugin author, and by default is passed unchanged from Falco/the application using the plugin framework to the plugin. However, semi-structured formats like JSON/YAML are preferable to free-form text. In those cases, the plugin author can provide a schema describing the config string contents by implementing the optional get_init_schema function. If so, the init function can assume the passed-in configuration string to always be well-formed, and can avoid performing any error handling. The plugin framework will take care of automatically parsing it against the provided schema and generating ad-hoc errors accordingly. Please refer to the documentation of get_init_schema for more details.\nIf a non-NULL ss_plugin_t* state is returned, then subsequent invocations of init must not return the same ss_plugin_t * value again, unless it has been disposed with destroy first.\ndestroy void plugin_destroy(ss_plugin_t *s) [Required: yes] This function frees any resources held in the ss_plugin_t struct. Afterwards, the handle should be considered destroyed and no further API functions will be called with that handle.\nget_last_error const char* plugin_get_last_error(ss_plugin_t* s) [Required: yes] This function is called by the framework after a prior call returned an error. The plugin should return a meaningful error string providing more information about the most recent error.\nget_init_schema const char* plugin_get_init_schema(ss_plugin_schema_type* schema_type) [Required: no] This function returns a schema that describes the configuration to be passed to init during plugin initialization. The return value is a C string, with memory owned by the plugin, representing the configuration schema. The type of schema returned is compliant with the ss_plugin_schema_type enumeration, and is written inside the schema_type output argument.\nAlthough this function is non-required, it is common to implement it due to the benefits it brings. If get_init_schema is correctly implemented, the init function can assume the passed-in configuration string to always be well-formed. The plugin framework will take care of automatically parsing it against the provided schema and generating ad-hoc errors accordingly. This also serves as a piece of documentation for users about how the plugin needs to be configured.\nCurrently, the plugin framework only supports the JSON Schema format, which is represented by the SS_PLUGIN_SCHEMA_JSON enum value. If a plugin defines a JSON Schema, the framework will require the init configuration string to be a valid json-formatted string.\nWriting the dummy enum value SS_PLUGIN_SCHEMA_NONE inside schema_type is equivalent to avoiding implementing the get_init_schema function itself, which ends up with the framework treating the init configuration as an opaque string with no additional checks.\nset_config ss_plugin_rc plugin_set_config(ss_plugin_t* s, const ss_plugin_set_config_input* i) [Required: no] Sets a new plugin configuration when provided by the framework. The new configuration is provided by config as a string in ss_plugin_set_config_input* i.\nThis function should return:\nSS_PLUGIN_SUCCESS (0) if the config is accepted SS_PLUGIN_FAILURE (1) if the config is rejected If rejected, the plugin should provide context in the string returned by get_last_error() before returning.\nget_metrics ss_plugin_metric* plugin_get_metrics(ss_plugin_t* s, uint32_t* num_metrics) [Required: no] This function returns the pointer to the first element of an array containing plugin-provided custom metrics.\nEach element of the array is a ss_plugin_metric which is defined in the plugin API as follows:\ntypedef struct ss_plugin_metric { const char* name; //Opaque string representing the metric name. ss_plugin_metric_type type; // Metric type, indicates whether the metric value is monotonic or non-monotonic. ss_plugin_metric_value value; // Metric numeric value. ss_plugin_metric_value_type value_type; // Metric value data type, e.g. `uint64_t`. } ss_plugin_metric; Each metric defines its own name, value, type (monotonic or non-monotonic) and value type (data type of its numeric value).\nThe argument num_metrics is a return argument and must be set to the length of the array before returning. It can be set to 0 if no metrics are provided.\nEvent Sourcing Capability API get_id uint32_t plugin_get_id() [Required: varies] This should return the event ID allocated to your plugin. During development and before receiving an official event ID, you can use the \u0026quot;Test\u0026quot; value of 999.\nThis function is required if get_event_source is defined and returns a non-empty string, otherwise it is considered optional. Returning zero is equivalent to not implementing the function. If the plugin has a non-zero ID and a non-empty event source, then its next_batch function is allowed to only return events of plugin type (code 322) with its own plugin ID and event source.\nget_event_source const char* plugin_get_event_source() [Required: varies] This function returns a C string, with memory owned by the plugin, containing the plugin's event source. This event source is used for:\nAssociating Falco rules with plugin events--A Falco rule with a source: gizmo property will run on all events returned by the gizmo plugin's next_batch function. Linking together plugins with field extraction capability and plugins with event sourcing capability. The first can list a given event source like gizmo in its get_extract_event_sources function, and they will get an opportunity to extract fields from all events returned by the \u0026quot;gizmo\u0026quot; plugin. Ensuring that only one plugin at a time is loaded for a given source. When defining a source, make sure it accurately describes the events from your plugin (e.g. use aws_cloudtrail for AWS CloudTrail events, not json or logs) and doesn't overlap with the source of any other plugin with event sourcing capability.\nThe only time where duplicate sources make sense are when a group of plugins can use a standard data format for a given event. For example, plugins might extract k8s_audit events from multiple cloud sources like gcp, azure, aws, etc. If they all format their events as json objects that have identical formats as one could obtain by using K8s Audit hooks, then it would make sense for the plugins to use the same source.\nThis function is required if get_id is defined and returns a non-zero ID, otherwise it is considered optional. Returning an empty string is equivalent to not implementing the function. If the plugin has a non-zero ID and a non-empty event source, then its next_batch function is allowed to only return events of plugin type (code 322) with its own plugin ID and event source.\nopen ss_instance_t* plugin_open(ss_plugin_t* s, const char* params, int32_t* rc) [Required: yes] This function is called to \u0026quot;open\u0026quot; a stream of events. The interpretation of a stream of events is up to the plugin author, but think of plugin_init as initializing the plugin software, and plugin_open as configuring the software to return events. Using a streaming audio analogy, plugin_init turns on the app, and plugin_open starts a streaming audio channel.\nThe same general guidelines apply for plugin_open as do for plugin_init:\nAll state related to sourcing a stream of events should be in the returned ss_instance_t pointer. Return 0 on success, 1 on error. Be ready to return an error via plugin_get_last_error on error. The plugin should support concurrent open sessions at once. Unlike plugin-level state, it's very likely that the plugin framework might call plugin_open multiple times for a given plugin. On error, do not return any instance struct, as the plugin framework will not call plugin_close. If a non-NULL ss_instance_t* instance is returned, then subsequent invocations of open must not return the same ss_instance_t* value again, unless it has been disposed with close first.\nclose void plugin_close(ss_plugin_t* s, ss_instance_t* h) [Required: yes] This function closes a stream of events previously started via a call to plugin_open. Afterwards, the stream should be considered closed and the framework will not call plugin_next_batch/plugin_extract_fields with the same ss_instance_t pointer.\nnext_batch int32_t plugin_next_batch(ss_plugin_t* s, ss_instance_t* h, uint32_t *nevts, ss_plugin_event ***evts) [Required: yes] This function is used to return a set of next events to the plugin framework, given a plugin state and open instance.\n*evts should be updated to an allocated contiguous array of ss_plugin_event pointers. The memory for the structs array is owned by the plugin and should be held until the next call to plugin_next_batch. *nevts should be updated with the number of events returned.\nAn event is represented by a ss_plugin_event struct, which observes the same format of the libscap event block specification.\nThis function should return:\nSS_PLUGIN_SUCCESS (0) on success SS_PLUGIN_FAILURE (1) on failure SS_PLUGIN_TIMEOUT (-1) on non-error but there are no events to return. SS_PLUGIN_EOF (6) when the stream of events is complete. If the plugin receives a SS_PLUGIN_FAILURE, it will close the stream of events by calling plugin_close.\nIf a plugin implements a specific event source (get_id is non-zero and get_event_source is non-empty), then, it is only allowed to produce events of type plugin (code 322) containing its own plugin ID (as returned by get_id). In such a case, when an event contains a zero plugin ID, the framework automatically sets the plugin ID of the event to the one of the plugin. If a plugin does not implement a specific event source, it is allowed to produce events of any of the types supported by the libscap specific.\nSS_PLUGIN_TIMEOUT should be returned whenever no events can be returned immediately. This ensures that the plugin framework is not stalled waiting for a response from plugin_next_batch. When the framework receives a SS_PLUGIN_TIMEOUT, it will keep the stream of events open and call plugin_next_batch again later.\nThis function can be invoked concurrently by multiple threads, each with distinct and unique parameter values. The value of the ss_plugin_event*** output parameter must be uniquely attached to the ss_instance_t* parameter value. The pointer must not be shared across multiple distinct ss_instance_t* values.\nget_progress const char* plugin_get_progress(ss_plugin_t* s, ss_instance_t* h, uint32_t* progress_pct) [Required: no] If the plugin exports this function, the framework will periodically call it after open to return how much of the event stream has been read. If a plugin does not provide a bounded stream of events (for example, events coming from a file or other source that has an ending), it should not export this function.\nIf not exported, the plugin framework will not print meaningful process indicators while processing event streams.\nWhen called, the progress_pct pointer should be updated with the read progress, as a number between 0 (no data has been read) and 10000 (100% of the data has been read). This encoding allows the engine to print progress decimals without requiring to deal with floating point numbers (which could cause incompatibility problems with some languages).\nThe return value is an string representation of the read progress, with the memory owned by the plugin. This might include the progress percentage combined with additional context added by the plugin. The plugin can return NULL. In this case, the framework will use the progress_pct value instead.\nThis function can be invoked concurrently by multiple threads, each with distinct and unique parameter values. If the returned pointer is non-NULL, then it must be uniquely attached to the ss_instance_t* parameter value. The pointer must not be shared across multiple distinct ss_instance_t* values.\nevent_to_string const char* plugin_event_to_string(ss_plugin_t *s, const ss_plugin_event_input *evt) [Required: no] This function is used to return a printable representation of an event. The memory is owned by the plugin and can be freed on the next call to plugin_event_to_string. It is used in filtering/output expressions as the built-in field evt.plugininfo. Even if implemented, this function is ignored if a plugin does not implement a specific event source (get_id is undefined or returns zero, and get_event_source is undefined or returns an empty string).\nThe string representation should be on a single line and contain important information about the event. It is not necessary to return all information from the event. Simply return the most important fields/properties of the event that provide a useful default representation.\nHere is an example output, from the cloudtrail plugin:\nus-east-1 masters.some-demo.k8s.local s3 GetObject Size=0 URI=s3://some-demo-env/some-demo.k8s.local/backups/etcd/events/control/etcd-cluster-created This function can be invoked concurrently by multiple threads, each with distinct and unique parameter values. If the returned pointer is non-NULL, then it must be uniquely attached to the ss_plugin_t* parameter value. The pointer must not be shared across multiple distinct ss_plugin_t* values.\nlist_open_params const char* plugin_list_open_params(ss_plugin_t* s, ss_plugin_rc* rc) [Required: no] This function returns a list of suggested values that are valid parameters for the open plugin function. Although non-required, this function is useful to instruct users about potential valid parameters for opening a stream of events. Implementing this function also brings additional usage documentation for the plugin, and allows makes it more usable with automated tools.\nThe returned value is a json string, with memory owned by the plugin, which contains an array of objects. Each object describes one suggested value for the open function. Here's an example:\n[ {\u0026#34;value\u0026#34;: \u0026#34;resource1\u0026#34;, \u0026#34;desc\u0026#34;: \u0026#34;An example of openable resource\u0026#34;}, {\u0026#34;value\u0026#34;: \u0026#34;resource2\u0026#34;, \u0026#34;desc\u0026#34;: \u0026#34;Another example of openable resource\u0026#34;} { \u0026#34;value\u0026#34;: \u0026#34;res1;res2;res3\u0026#34;, \u0026#34;desc\u0026#34;: \u0026#34;Some names\u0026#34;, \u0026#34;separator\u0026#34;: \u0026#34;;\u0026#34; } ] Each object has the following properties:\nvalue: a string usable as a parameter for open desc: (optional) a string with that describes the meaning of value. separator: (optional) a string representing a separator string in case value represents a list of concatenated values. This can be used by plugins to specify an open param that represents more than one source, in which case they can be separated by the separator substring. It's a plugin responsibility to specify the separator string. Field Extraction Capability API get_fields const char* plugin_get_fields() [Required: yes] This function should return the set of fields supported by the plugin. Remember, a field is a name (e.g. proc.name) that can extract a value (e.g. nginx) from an event (e.g. a syscall event involving a process). The return value is a string whose memory is owned by the plugin. The string is json formatted and contains an array of objects. Each object describes one field. Here's an example:\n[ {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;gizmo.field1\u0026#34;, \u0026#34;arg\u0026#34;: {\u0026#34;isRequired\u0026#34;: true, \u0026#34;isKey\u0026#34;: true}, \u0026#34;desc\u0026#34;: \u0026#34;Describing field 1\u0026#34;}, {\u0026#34;type\u0026#34;: \u0026#34;uint64\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;gizmo.field2\u0026#34;, \u0026#34;desc\u0026#34;: \u0026#34;Describing field 2\u0026#34;, properties: [\u0026#34;hidden\u0026#34;]} ] Each object has the following properties:\ntype: one of \u0026quot;string\u0026quot;, \u0026quot;uint64\u0026quot;, \u0026quot;bool\u0026quot;, \u0026quot;reltime\u0026quot;, \u0026quot;abstime\u0026quot;, \u0026quot;ipaddr\u0026quot;, \u0026quot;ipnet\u0026quot; name: a string with a name for the field. By convention, this is a dot-separated path of names. Use a consistent first name e.g. \u0026quot;ct.xxx\u0026quot; to help filter authors associate the field with a given plugin. isList: (optional) If present and set to true, notes that the field extracts a list of values. Fields of this kind can only be used with the in and intersects filtering operators. For list fields, extracting single values means extracting lists of length equal to 1. arg: (optional) if present, notes that the field can accept an argument e.g. field[arg]. More precisely, the following flags could be specified: isRequired: if true, the argument is required. isIndex: if true, the field is numeric. isKey: if true, the field is a string. If isRequired is true, one between isIndex and isKey must be true, to specify the argument type. If isRequired is false, but one between isIndex and isKey is true, the argument is allowed but not required. display: (optional) If present, a string that will be used to display the field instead of the name. Used in tools like wireshark. desc: a string with a short description of the field. This will be used in help output so be concise and descriptive. properties: (optional) If present, an array of additional properties that apply to the field. The value is an array of strings that can be one of the following: hidden: Do not display the field when using programs like falco --list to list the set of supported fields. conversation: This field is applicable for use in wireshark conversations, and denotes that the field represents one half of a \u0026quot;conversation\u0026quot; that can be shown in the conversations or endpoints view. info: Also applicable for use in wireshark, and denotes that it should be appended to the \u0026quot;info\u0026quot; column in the wireshark event list. When defining fields, keep the following guidelines in mind:\nField names should generally have the plugin name/event source as the first component, and usually have one or two additional components. For example, gizmo.pid is preferred over gizmo.process.id.is. If a plugin has a moderately large set of fields, using components to group fields may make sense (e.g. cloudtrail.s3.bytes.in and cloudtrail.s3.bytes.out). Fields should be idempotent: for a given event, the value for a field should be the same regardless of when/where the event was generated. Fields should be neutral: define fields that extract properties of the event (e.g. \u0026quot;source ip address\u0026quot;) rather than judgements (e.g. \u0026quot;source ip address is associated with a botnet\u0026quot;). extract_fields int32_t plugin_extract_fields(ss_plugin_t *s, const ss_plugin_event_input *evt, const ss_plugin_field_extract_input* in) [Required: yes] This function is used to return the value for one or more field names that were returned in plugin_get_fields. The framework provides an event and an input containing an array of ss_plugin_extract_field structs. Each struct has one field name/type, and the plugin fills in each struct with the corresponding value for that field.\nThe format of the ss_plugin_extract_field struct is the following:\n// The noncontiguous numbers are to maintain equality with underlying // falcosecurity/libs types. typedef enum ss_plugin_field_type { // A 64bit unsigned integer. FTYPE_UINT64 = 8, // A printable buffer of bytes, NULL terminated FTYPE_STRING = 9, // A relative time. Seconds * 10^9 + nanoseconds. 64bit. FTYPE_RELTIME = 20, // An absolute time interval. Seconds from epoch * 10^9 + nanoseconds. 64bit. FTYPE_ABSTIME = 21, // A boolean value, 4 bytes. FTYPE_BOOL = 25, // Either an IPv4 or IPv6 address. The length indicates which one it is. FTYPE_IPADDR = 40, // Either an IPv4 or IPv6 network. The length indicates which one it is. // The field encodes only the IP address, so this differs from FTYPE_IPADDR, // from the way the framework perform runtime checks and comparisons. FTYPE_IPNET = 41, }ss_plugin_field_type; typedef struct ss_plugin_extract_field { union { const char** str; uint64_t* u64; uint32_t* u32; ss_plugin_bool* boolean; ss_plugin_byte_buffer* buf; } res; uint64_t res_len; uint32_t field_id; const char* field; const char* arg_key; uint64_t arg_index; bool arg_present; uint32_t ftype; bool flist; } ss_plugin_extract_field; For each struct, the plugin fills in field_id/field/arg/ftype with the field. field_id is the index into the original list of fields returned by plugin_get_fields, and allows for faster mapping to a plugin's set of fields. The plugin should fill in res_len and res with a pointer to an array of values of appropriate type for the field, depending on the field type ftype. If the field type is FTYPE_STRING, res should be updated to point to an string with the string value, with memory owned by the plugin. The plugin should retain this memory until the next call to plugin_extract_fields.\nIf res_len is set to zero, the plugin framework assumes that res is undefined and will not use it. Setting a res_len value grater than 1 is allowed only for fields for which isList is defined as true.\nThis function can be invoked concurrently by multiple threads, each with distinct and unique parameter values. The value of the ss_plugin_extract_field* output parameter must be uniquely attached to the ss_plugin_t* parameter value. The pointer must not be shared across multiple distinct ss_plugin_t* values.\nget_extract_event_sources const char* plugin_get_extract_event_sources() [Required: no] This function allows the plugin to restrict the kinds of events where the plugin's extract_fields method will be called. Valid event source names are the ones returned by the get_event_source function of plugins with event sourcing capability, or syscall for indicating support to non-plugin events. The return value should be a string containing a json array of compatible event sources, with memory owned by the plugin. Here's an example:\n[\u0026#34;aws_cloudtrail\u0026#34;, \u0026#34;gcp_cloudtrail\u0026#34;] This implies that the plugin can potentially extract values from events that have a source aws_cloudtrail or gcp_cloudtrail.\nThis function is optional. If the plugin does not export this function or if it returns an empty array (or NULL), then if the plugin has sourcing capability, and implements a specific event source, it will only receive events matching its event source, otherwise the framework will assume the plugin can receive events from all event sources.\nget_extract_event_types uint16_t* plugin_get_extract_event_types(uint32_t* numtypes) [Required: no] This function allows the plugin to restrict the kinds of events where the plugin's extract_fields method will be called. The return value is an array of integers representing the event types that the plugin is capable of processing for field extraction. Events with types that are not present in the returned list will not be received by the plugin. The event types follow the enumeration from the libscap specific.\nThis function is optional. If the plugin does not export this function or if it returns an empty array (or NULL), the plugin will receive every event type if the result of get_extract_event_sources (either default or custom) is compatible with the syscall event source, otherwise the plugin will only receive events of plugin type (code 322).\nEvent Parsing Capability API parse_event ss_plugin_rc plugin_parse_event(ss_plugin_t *s, const ss_plugin_event_input *evt, const ss_plugin_event_parse_input* in) [Required: yes] Receives an event from the current capture and parses its content. The plugin is guaranteed to receive an event at most once, after any operation related the event sourcing capability, and before any other operation related to the field extraction capability. The returned rc value should be SS_PLUGIN_SUCCESS (0) on success, SS_PLUGIN_FAILURE (1) on failure.\nThe framework provides an event and an input. The event pointer is allocated and owner by the framework, and it is not guaranteed that to refer to the same memory or data returned by the last next_batch call (in case the same plugin also supports the event sourcing capability). The input is a vtable containing callbacks towards the plugin's owner that can be used by the plugin for performing read/write operations on state tables not owned by itself, for which it obtained accessors at initialization time. The plugin does not need to go through this vtable in order to read and write from a table it owns.\nThis function can be invoked concurrently by multiple threads, each with distinct and unique parameter values. The value of the ss_plugin_event_parse_input* output parameter must be uniquely attached to the ss_plugin_t* parameter value. The pointer must not be shared across multiple distinct ss_plugin_t* values.\nget_parse_event_sources const char* plugin_get_parse_event_sources() [Required: no] This function allows the plugin to restrict the kinds of events where the plugin's parse_event method will be called. Valid event source names are the ones returned by the get_event_source function of plugins with event sourcing capability, or syscall for indicating support to non-plugin events. The return value should be a string containing a json array of compatible event sources, with memory owned by the plugin.\nThis function is optional. If the plugin does not export this function or if it returns an empty array (or NULL), then if the plugin has sourcing capability, and implements a specific event source, it will only receive events matching its event source, otherwise the framework will assume the plugin can receive events from all event sources.\nget_parse_event_types uint16_t* plugin_get_parse_event_types(uint32_t* numtypes) [Required: no] This function allows the plugin to restrict the kinds of events where the plugin's parse_event method will be called. The return value is an array of integers representing the event types that the plugin is capable of processing for field extraction. Events with types that are not present in the returned list will not be received by the plugin. The event types follow the enumeration from the libscap specific.\nThis function is optional. If the plugin does not export this function or if it returns an empty array (or NULL), the plugin will receive every event type if the result of get_parse_event_sources (either default or custom) is compatible with the syscall event source, otherwise the plugin will only receive events of plugin type (code 322).\nAsync Events Capability API get_async_event_sources const char* plugin_get_async_event_sources() [Required: no] The return value should be a string containing a json array of compatible event sources, with memory owned by the plugin. The list describes the event sources for which this plugin is capable of injecting async events in the event stream of a capture.\nThis function is optional. If the plugin does not export this function or if it returns an empty array (or NULL), then the async events produced by a plugin will be injected in the event stream of any source.\nget_async_events const char* plugin_get_async_events() [Required: yes] Return a string describing the name list of all asynchronous events that this plugin is capable of pushing into a live event stream. The framework can reject async events produced by a plugin if their name is not on the name list returned by this function. The return value should be a string containing a json array of compatible event sources, with memory owned by the plugin.\nset_async_event_handler ss_plugin_rc plugin_set_async_event_handler(ss_plugin_t* s, ss_plugin_owner_t* owner, const ss_plugin_async_event_handler_t handler) [Required: yes] Sets a function handler that allows the plugin to send events asynchronously to its owner during a live event capture. The handler is a thread-safe function that can be invoked concurrently by multiple threads. The asynchronous events must be encoded as an async event type (code 402) as for the libscap specific. The returned rc value should be SS_PLUGIN_SUCCESS (0) on success, SS_PLUGIN_FAILURE (1) on failure.\nThe memory of events sent to the async event handler function must be owned by the plugin and is not retained by the owner after the event handler returns. The async event handler function is defined as follows:\n// Function handler used by plugin for sending asynchronous events to the // Falcosecurity libs during a live event capture. The asynchronous events // must be encoded as an async event type (code 402) as for the libscap specific. // The function returns SS_PLUGIN_SUCCESS in case of success, or // SS_PLUGIN_FAILURE otherwise. If a non-NULL char pointer is passed for // the \u0026#34;err\u0026#34; argument, it will be filled with an error message string // in case the handler function returns SS_PLUGIN_FAILURE. The error string // has a max length of PLUGIN_MAX_ERRLEN (termination char included) and its // memory must be allocated and owned by the plugin. typedef ss_plugin_rc (*ss_plugin_async_event_handler_t)(ss_plugin_owner_t* o, const ss_plugin_event *evt, char* err); The plugin can start sending async events through the passed-in handler right from the moment this function is invoked. set_async_event_handler can be invoked multiple times during the lifetime of a plugin. In that case, the registered function handler remains valid up until the next invocation of set_async_event_handler on the same plugin, after which the new handler set must replace any already-set one. If the handler is set to a NULL function pointer, the plugin is instructed about disabling or stopping the production of async events. If a NULL handler is set, and an asynchronous job has been started by the plugin before, the plugin should stop the job and wait for it to be finished before returning from this function. Although the event handler is thread-safe and can be invoked concurrently, this function is still invoked by the framework sequentially from the same thread.\nThe C++ example below shows how an async event handler can be correctly used from an asynchronous thread with proper start and stop conditions:\ntypedef struct my_plugin { std::thread async_thread; std::atomic\u0026lt;bool\u0026gt; async_thread_run; } my_plugin; extern \u0026#34;C\u0026#34; ss_plugin_t* plugin_init(const ss_plugin_init_input* in, ss_plugin_rc* rc) { my_plugin *ret = new my_plugin(); ret-\u0026gt;async_thread_run = false; *rc = SS_PLUGIN_SUCCESS; return ret; } extern \u0026#34;C\u0026#34; void plugin_destroy(ss_plugin_t* s) { // stop the async thread if it\u0026#39;s running my_plugin *ps = (my_plugin *) s; if (ps-\u0026gt;async_thread_run) { ps-\u0026gt;async_thread_run = false; if (ps-\u0026gt;async_thread.joinable()) { ps-\u0026gt;async_thread.join(); } } delete ps; } ... extern \u0026#34;C\u0026#34; ss_plugin_rc plugin_set_async_event_handler(ss_plugin_t* s, ss_plugin_owner_t* owner, const ss_plugin_async_event_handler_t handler) { my_plugin *ps = (my_plugin *) s; // stop the async thread if it\u0026#39;s running if (ps-\u0026gt;async_thread_run) { ps-\u0026gt;async_thread_run = false; if (ps-\u0026gt;async_thread.joinable()) { ps-\u0026gt;async_thread.join(); } } // if an handler is provided, launch an async worker if (handler) { ps-\u0026gt;async_thread_run = true; ps-\u0026gt;async_thread = std::thread([ps, owner, handler]() { char err[PLUGIN_MAX_ERRLEN]; while (ps-\u0026gt;async_thread_run;) { ss_plugin_event* evt = ps-\u0026gt;do_some_work(); if (handler(owner, evt, err) != SS_PLUGIN_SUCCESS) { // report the error somehow } } }); } return SS_PLUGIN_SUCCESS; } Async events encode a plugin ID that defines its event source. However, this value is set by the framework when the async event is received, and is set to the ID associated to the plugin-defined event source currently open during a live capture, or zero in case of the syscall event source. The event source assigned by the framework to the async event can only be among the ones compatible with the list returned by get_async_event_sources.\nAsync events encode a string representing their event name, which is used for runtime matching and define the encoded data payload. Plugins are allowed to only send async events with one of the names expressed in the list returned by get_async_events. The name of an async event acts as a contract on the encoding of the data payload of all async events with the same name.\nLibscap Event Block Specification Libscap, the Falcosecurity libs component responsible of event captures and control, proposes and supports a specification that regulates the way system, kernel, and plugin events are encoded. The same specification also defines the encoding of SCAP capture files, that can be used by the Falcosecurity libs to record and replay event streams. In the specification, events are defined as a specific block type of the pcap-ng file format. All the event types and the associated parameters supported by libscap are defined by the libscap's event table. The plugin API fully shares and observes the libscap's event definitions, and uses them for both reading and writing events from/to the framework.\nAs for the libscap specific, an event is represented as a contiguous region of memory composed by a header and a list of parameters appended to it, in the form of:\n// | evt header | len param 1 (2B/4B) | ... | len param N (2B/4B) | data param 1 | ... | data param N | typedef struct ss_plugin_event { uint64_t ts; /* timestamp, in nanoseconds from epoch */ uint64_t tid; /* the tid of the thread that generated this event */ uint32_t len; /* the event len, including the header */ uint16_t type; /* the event type */ uint32_t nparams; /* the number of parameters of the event */ } ss_plugin_event; The event header is composed of:\nts: the event timestamp, in nanoseconds since the epoch. Can be (uint64_t)-1, in which case the framework will automatically fill the event time with the current time. tid: the tid of the thread that generated this event. Can be (uint64_t)-1 in case no thread is specified, such as when generating a plugin event (type code 322). len: the event len, including the header type: the code of the event, as per the ones supported by the libscap specific. This dictates the number and kind of parameters, and whether the length is encoded as a 2 bytes or 4 bytes integer. nparams: the number of parameters of the event Further and more formal documentation will be available in the future...\nState Tables API In the plugin framework, state tables are simple key-value mappings representing a piece of state owned by a component of the Falcosecurity libs or defined by a plugin. The plugin API declares formal abstract definitions for state tables and provides means for plugins to access the state owned by other components of the framework, define and own their own state, and make it accessible externally. In this context, a component of the framework is an abstract entity that could represent a given piece of machinery within the Falco libraries or any other plugin loaded at runtime.\nBasic Concepts A state table is a key-value map that can be used for storing pieces of state within the plugin framework. State tables are an abstract concept, and the plugin API does not enforce any specific implementation. Instead, the API specifies interface boundaries in the form of C virtual tables of methods representing the behavior of state tables. This allows the plugin API to remain flexible, abstract, and multi-language by nature. The model by which state tables work is defined by the notions of ownership, registration, and discovery.\nEvery state table must have an owner, which is responsible of managing the table's memory and of implementing all the functions of the state tables API. Owners can either be plugins or any of the other actors that are part of the Falcosecurity libraries. For example, libsinsp is the owner of the threads table, which is a key-value store where the key is a thread ID of a Linux machine and the value is a set of information describing a Linux thread. Plugins can access the threads table of libsinsp for retrieving thread information given a thread ID, reading and writing the info fields, extending the info with additional metadata, and do much more. However, plugins are never responsible of managing the memory and the implementation of the threads table, as it is owned by libsinsp only. Instead, plugins can do the same by defining their own stateful components and implementing the required interface functions to register them as \u0026quot;state tables\u0026quot;. Stateful components must be registered in the framework in order to be considered \u0026quot;state tables\u0026quot;. Libsinsp, which owns the plugins loaded at runtime, also holds a \u0026quot;table registry\u0026quot; that is the source of truth for all the state tables known at runtime. Once a state table is registered in the table registry, it is discoverable by all the actors and plugins running in the context of the same Falcosecurity libs instance.\nThe way plugins can interact with state tables is through discovery and the usage of accessors. At initialization time (in the init function), plugins are provided interface functions that allow them to list all the state tables available at runtime and obtaining \u0026quot;accessors\u0026quot; for later usage. An accessor is an opaque pointers obtained at initialization time and that can be used later (e.g. when parsing an event or when extracting a field) for accessing a given table or the fields of its entries. Considering the example of the threads table, in its init function a given plugin could obtain an accessor to the table and to some of the fields of each thread info (such as the pid or the comm) and store them in its plugin state. Later, when extracting a field, the same plugin would be available to query the threads table for a given thread ID (perhaps obtained by reading the event payload of a syscall) by using the table accessor, and then reading the pid of the obtained thread by using the field accessor.\nInherently, the plugin API also enable plugins to define their own state tables and register them in the table registry. Once that's done, the registered state table will be visible to all other plugins just like the threads table, without knowing nor caring about which actor is owning it. The state table owned by the plugin will be discoverable through the table registry by the plugin itself too. However, plugins owning a given table are not forced to go through the state tables interface in order to operate on it (conversely, this could also be the less efficient choice). Plugins can implement their own state as they prefer, whereas the purpose of the state tables interface is solely to make that state available to other actors in the framework. Coherently, table owners can also decide \u0026quot;how much\u0026quot; of a table they want the other components to have visibility of. For example, libsinsp can access more info and functionalities on the threads table than what it makes available through the state table interface, which is also natural considering that its implementation is hidden and can be arbitrary.\nThe set of state tables made available by a given plugin or Falcosecurity libs actor, and the set of fields and operations available for each of those table, take part of the semantic versioned UX contract of that plugin or actor. For example, removing a given table or table field from libsinsp can be considered a breaking change that must reflected by the version number of the Falcosecurity libs. The same applies for the version of each plugin and the state tables declared by them.\nAccess and Consistency State tables are dynamic structures. Each table is defined by a given key type, which can be any of the types supported by the ss_plugin_state_type enumeration. Then, the each key-value mappings contained in the table are referred to as table entries. Each entry has a specific set of information fields, which is shared across all the entries of the same table. Each field is named and has a specific type. The set of fields for the entries of a given table is defined dynamically at runtime and can be extended by different actors. For example, libsinsp populates the threads table with a given set of information fields for each table's entry (representing a given thread info), and plugins can read and write the value of those fields by obtaining accessors for those. However, plugins also have the opportunity of defining new fields inside the threads table, with a new unique name and a specific type, and libsinsp will be responsible of hosting that new piece of information for each thread and make it available to all actors in the framework. The same can happen for tables defined by any plugin.\nGiven that state tables can get modified by different actors at runtime, there has to be a deterministic disambiguation about consistency of table edits and visibility of those changes. The plugin API implements this by guaranteeing a deterministic and non-changing total ordering of all the actors in the system. Considering a given ordering, an actor will have visibility only over the changes applied by actors coming before it in the given ordering. In the Falcosecurity libs and the plugin framework, the guaranteed order is the one by which plugins are loaded at runtime. The first actor in the order is always libsinsp itself, which means that all plugins will always see all the table modifications authored by libsinsp at a given point in time. Then, plugins are ordered by following their loading order at runtime. This means that if Plugin B is loaded in Falco after Plugin A, then Plugin B will see all the table changes performed by Plugin A at runtime, but not the contrary (however, they'll both have visibility over the changes performed by libsinsp). As such the plugins loading order in Falco can be functionally relevant.\nSubtables and complex data types The plugin framework supports a special table field type which is the table type. Table entries can use this field to store the handle to another table, which means each entry can have its own subtables.\nFor example, the threads table has a field named file_descriptors. This field allows accessing the file descriptor table of every thread, making it possible to access useful information about a specific open file descriptor like file name, pid, and much more.\nThis also unlocks the ability for tables to store/access arrays, maps or even more complex data types. The plugin can \u0026quot;wrap\u0026quot; the complex type in a table by implementing the interface functions for that type, allowing the complex data types to be stored as a subtable.\nObtaining Accessors Before performing any operation over state tables, plugins must first obtain accessors for each of them. This can happen only at initialization time through a vtable that is passed only to the init plugin function. The vtable allows plugins to discover all the tables registered in the framework, get accessors for them, and register their own tables. Once an accessor is obtained, plugins must maintain it up until they are destroyed, and use it during functions related to specific capabilities (e.g. field extraction, event parsing). The vtable passed to init is reported below.\n// Vtable for controlling and the fields for the entries of a state table. // This allows discovering the fields available in the table, defining new ones, // and obtaining accessors usable at runtime for reading and writing the fields\u0026#39; // data from each entry of a given state table. typedef struct { // Returns a pointer to an array containing info about all the fields // available in the entries of the table. nfields will be filled with the number // of elements of the returned array. The array\u0026#39;s memory is owned by the // tables\u0026#39;s owner. Returns NULL in case of error. ss_plugin_table_fieldinfo* (*list_table_fields)(ss_plugin_table_t* t, uint32_t* nfields); // // Returns an opaque pointer representing an accessor to a data field // present in all entries of the table, given its name and type. // This can later be used for read and write operations for all entries of // the table. The pointer is owned by the table\u0026#39;s owner. // Returns NULL in case of issues (including when the field is not defined // or it has a type different than the specified one). ss_plugin_table_field_t* (*get_table_field)(ss_plugin_table_t* t, const char* name, ss_plugin_state_type data_type); // // Defines a new field in the table given its name and data type, // which will then be available in all entries contained in the table. // Returns an opaque pointer representing an accessor to the newly-defined // field. This can later be used for read and write operations for all entries of // the table. The pointer is owned by the table\u0026#39;s owner. // Returns NULL in case of issues (including when a field is defined multiple // times with different data types). ss_plugin_table_field_t* (*add_table_field)(ss_plugin_table_t* t, const char* name, ss_plugin_state_type data_type); } ss_plugin_table_fields_vtable; typedef struct { // Returns a pointer to an array containing info about all the tables // registered in the plugin\u0026#39;s owner. ntables will be filled with the number // of elements of the returned array. The array\u0026#39;s memory is owned by the // plugin\u0026#39;s owner. Returns NULL in case of error. ss_plugin_table_info* (*list_tables)(ss_plugin_owner_t* o, uint32_t* ntables); // // Returns an opaque accessor to a state table registered in the plugin\u0026#39;s // owner, given its name and key type. Returns NULL if an case of error. ss_plugin_table_t* (*get_table)(ss_plugin_owner_t* o, const char* name, ss_plugin_state_type key_type); // // Registers a new state table in the plugin\u0026#39;s owner. Returns // SS_PLUGIN_SUCCESS in case of success, and SS_PLUGIN_FAILURE otherwise. // The state table is owned by the plugin itself, and the input will be used // by other actors of the plugin\u0026#39;s owner to interact with the state table. ss_plugin_rc (*add_table)(ss_plugin_owner_t* o, const ss_plugin_table_input* in); // // Vtable for controlling operations related to fields on the state tables // registered in the plugin\u0026#39;s owner. ss_plugin_table_fields_vtable fields; } ss_plugin_init_tables_input; Obtaining subtables accessors Obtaining table accessors is a bit different for subtables.\nTable accessors can be only obtained at initialization time, however tables may be empty at this time, which means subtables may not yet exist. The solution to this problem is to create a table entry just to get its subtables.\nPlease note that this newly created entry is temporary and it should be used only at initialization time to obtain subtable accessors.\nThe following example shows how to obtain accessors for the file descriptor subtable:\nstruct plugin_state { ss_plugin_table_t* thread_table; ss_plugin_table_field_t* table_field_fdtable; ss_plugin_table_field_t* table_field_fdtable_name; }; static ss_plugin_t* plugin_init(const ss_plugin_init_input* in, ss_plugin_rc* rc) { plugin_state *ret = new plugin_state(); // get the accessor to the threads table ret-\u0026gt;thread_table = in-\u0026gt;tables-\u0026gt;get_table(in-\u0026gt;owner, \u0026#34;threads\u0026#34;, ss_plugin_state_type::SS_PLUGIN_ST_INT64); // get an accessor to the subtable field ret-\u0026gt;table_field_fdtable = in-\u0026gt;tables-\u0026gt;fields.get_table_field(ret-\u0026gt;thread_table, \u0026#34;file_descriptors\u0026#34;, ss_plugin_state_type::SS_PLUGIN_ST_TABLE); // create a new table entry auto entry = in-\u0026gt;tables-\u0026gt;writer_ext-\u0026gt;create_table_entry(ret-\u0026gt;thread_table); // read the subtable handle from the new entry ss_plugin_state_data data; in-\u0026gt;tables-\u0026gt;reader_ext-\u0026gt;read_entry_field(ret-\u0026gt;thread_table, entry, ret-\u0026gt;table_field_fdtable, \u0026amp;data); auto fdtable = data.table; //obtain the accessor to one of the subtable fields ret-\u0026gt;table_field_fdtable_name = in-\u0026gt;tables-\u0026gt;fields_ext-\u0026gt;get_table_field(fdtable, \u0026#34;name\u0026#34;, ss_plugin_state_type::SS_PLUGIN_ST_STRING); //destroy the temporary entry in-\u0026gt;tables-\u0026gt;writer_ext-\u0026gt;destroy_table_entry(ret-\u0026gt;thread_table, entry); } Accessing Tables After obtaining accessors for all the tables and fields a given plugin is interested into, they can be used for performing operations over tables at runtime. Table operations are split in the two \u0026quot;reading\u0026quot; and \u0026quot;writing\u0026quot; categories, each having their own vtable and set of functions. The \u0026quot;reader\u0026quot; and the \u0026quot;writer\u0026quot; vtables are passed to the interested plugin functions for different capabilities, depending on their scope. For example, the extract_fields function of the field extraction capability gets passed the state tables reader vtable, whereas the parse_event function of the event parsing capability has access to both the reader and writer vtables. This enforces users to only apply state tables modifications at event parsing time, leaving field extraction a \u0026quot;stateless\u0026quot; code path. The reader and writer vtables and their respective functions are reported below.\n// Vtable for controlling a state table for read operations. typedef struct { // Returns the table\u0026#39;s name, or NULL in case of error. // The returned pointer is owned by the table\u0026#39;s owner. const char*\t(*get_table_name)(ss_plugin_table_t* t); // // Returns the number of entries in the table, or ((uint64_t) -1) in // case of error. uint64_t (*get_table_size)(ss_plugin_table_t* t); // // Returns an opaque pointer to an entry present in the table at the given // key, or NULL in case of issues (including if no entry is found at the // given key). The returned pointer is owned by the table\u0026#39;s owner. ss_plugin_table_entry_t* (*get_table_entry)(ss_plugin_table_t* t, const ss_plugin_state_data* key); // // Reads the value of an entry field from a table\u0026#39;s entry. // The field accessor must be obtained during plugin_init(). // The read value is stored in the \u0026#34;out\u0026#34; parameter. // Returns SS_PLUGIN_SUCCESS if successful, and SS_PLUGIN_FAILURE otherwise. ss_plugin_rc (*read_entry_field)(ss_plugin_table_t* t, ss_plugin_table_entry_t* e, const ss_plugin_table_field_t* f, ss_plugin_state_data* out); } ss_plugin_table_reader_vtable; // Vtable for controlling a state table for write operations. typedef struct { // Erases all the entries of the table. // Returns SS_PLUGIN_SUCCESS if successful, and SS_PLUGIN_FAILURE otherwise. ss_plugin_rc (*clear_table)(ss_plugin_table_t* t); // // Erases an entry from a table at the given key. // Returns SS_PLUGIN_SUCCESS if successful, and SS_PLUGIN_FAILURE otherwise. ss_plugin_rc (*erase_table_entry)(ss_plugin_table_t* t, const ss_plugin_state_data* key); // // Creates a new entry that can later be added to the same table it was // created from. The entry is represented as an opaque pointer owned // by the plugin. Once obtained, the plugin can either add the entry // to the table through add_table_entry(), or destroy it through // destroy_table_entry(). Returns an opaque pointer to the newly-created // entry, or NULL in case of error. ss_plugin_table_entry_t* (*create_table_entry)(ss_plugin_table_t* t); // // Destroys a table entry obtained by from previous invocation of create_table_entry(). void (*destroy_table_entry)(ss_plugin_table_t* t, ss_plugin_table_entry_t* e); // // Adds a new entry to a table obtained by from previous invocation of // create_table_entry() on the same table. The entry is inserted in the table // with the given key. If another entry is already present with the same key, // it gets replaced. After insertion, table will be come the owner of the // entry\u0026#39;s pointer. Returns an opaque pointer to the newly-added table\u0026#39;s entry, // or NULL in case of error. ss_plugin_table_entry_t* (*add_table_entry)(ss_plugin_table_t* t, const ss_plugin_state_data* key, ss_plugin_table_entry_t* entry); // // Updates a table\u0026#39;s entry by writing a value for one of its fields. // The field accessor must be obtained during plugin_init(). // The written value is read from the \u0026#34;in\u0026#34; parameter. // Returns SS_PLUGIN_SUCCESS if successful, and SS_PLUGIN_FAILURE otherwise. ss_plugin_rc (*write_entry_field)(ss_plugin_table_t* t, ss_plugin_table_entry_t* e, const ss_plugin_table_field_t* f, const ss_plugin_state_data* in); } ss_plugin_table_writer_vtable; Accessing subtables Subtables handles can be obtained just like any other field, by reading the table type field of an entry.\nAfter obtaining subtables handles and fields accessors, accessing subtables is the same as accessing regular tables.\nThe following example shows how to access fields from the file_descriptors subtable from one of the entries of the threads table:\nss_plugin_rc plugin_parse_event(ss_plugin_t *s, const ss_plugin_event_input *ev, const ss_plugin_event_parse_input* in) { plugin_state *ps = (plugin_state *) s; ss_plugin_state_data tmp; // get an entry from the thread table tmp.s64 = ev-\u0026gt;evt-\u0026gt;tid; ss_plugin_table_entry_t* thread_entry = in-\u0026gt;table_reader_ext-\u0026gt;get_table_entry(ps-\u0026gt;thread_table, \u0026amp;tmp); // read the file_descriptors field from the entry in-\u0026gt;table_reader_ext-\u0026gt;read_entry_field(ps-\u0026gt;thread_table, thread_entry, ps-\u0026gt;table_field_fdtable, \u0026amp;tmp); ss_plugin_table_t* fdtable = tmp.table; // get an entry from the file descriptors table of the previously read thread tmp.s64 = 0; ss_plugin_table_entry_t* fd_entry = in-\u0026gt;table_reader_ext-\u0026gt;get_table_entry(fdtable, \u0026amp;tmp); // read a field from the entry in the file descriptors table in-\u0026gt;table_reader_ext-\u0026gt;read_entry_field(fdtable, fd_entry, ps-\u0026gt;table_field_fdtable_name, \u0026amp;tmp); } Registering State Tables On top of accessing tables owned by the framework or other plugins, each plugin can also make part (or all) of its state available to other actors in the framework in the form of state tables. In this case, the plugin is responsible of providing all the necessary vtables and their respective functions, just like the Falcosecurity libraries do for the tables owned by them (e.g. the threads table). Plugins have total freedom towards how the table is actually implemented, as long as they respect the API functions in the vtables and they own all the memory related to the table and its entries. Plugins also have the freedom of not supporting some of the functions of the vtables, however they are not allowed to pass NULL-pointing function references. The struct by which plugins register their state table and the related vtable functions is reported below.\n// Plugin-provided input passed to the add_table() callback of // ss_plugin_init_tables_input, that can be used by the plugin to inform its // owner about one of the state tables owned by the plugin. The plugin // is responsible of owning all the memory pointed by this struct and // of implementing all the API functions. These will be used by other // plugins loaded by the falcosecurity libraries to interact with the state // of a given plugin to implement cross-plugin state access. typedef struct { // The name of the state table. const char* name; // // The type of the sta table\u0026#39;s key. ss_plugin_state_type key_type; // // A non-NULL opaque pointer to the state table. // This will be passed as parameters to all the callbacks defined below. ss_plugin_table_t* table; // // Vtable for controlling read operations on the state table. ss_plugin_table_reader_vtable reader; // // Vtable for controlling write operations on the state table. ss_plugin_table_writer_vtable writer; // // Vtable for controlling operations related to fields on the state table. ss_plugin_table_fields_vtable fields; } ss_plugin_table_input; Thread-safety and Reproducibility State access is not thread-safe. Operations related to either discovery, reading, or writing, must all be executed in the synchronous context and within the thread in which the framework invokes the given plugin function that is capable of accessing tables. For example, plugins are only allowed to read from a table during the execution of extract_fields or parse_event, but they are not allowed to launch an asynchronous thread that reuses the same accessors to read from a table after any of those functions have returned.\nAlso, the previous sections imply that state tables can be operated on during the execution of various plugin functions, but that however only the parse_event function of the event parsing capability can perform write operations. This is by purpose and design due to the architecture of the Falcosecurity libraries themselves.\nThere may be use cases when the state update results of some asynchronous job and computation. For example, the Falcosecurity libraries implement the container metadata enrichment support by connecting to one or more container runtime sockets and fetching information asynchronously using a separate thread of the main event processing loop. In those cases, state updates must still happen synchronously. The async events capability is the strategy provided by the plugin framework. With that, plugins are provided with a thread-safe callback that they can use to inject asynchronous events in the currently-open event stream, and the framework will guarantee those events to be later received by functions such as parse_event or extract_fields just like any other events. Plugins can only safely utilize asynchronously-obtained information for state updates and field extraction through this messaging-like communication mode.\nAn additional effect of injecting asynchronous events in an event stream is that they can so be recorded in SCAP capture files, thus being reproducible when reading events later from that capture files. By having the asynchronous information recorded in the event stream, the event parsing and field extraction plugin functions will be able to work just like in live capture mode by also making all the state transitions reproducible and deterministic.\n","summary":"","tags":null,"title":"Falco Plugins API Reference","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/plugins/plugin-api-reference/"},{"category":"docs","content":"Plugins SDKs To facilitate the development of plugins, The Falco Project provides SDKs for multiple programming languages: Go, C++, and Rust. These SDKs provide flexibility for developers to choose the programming language they are most comfortable with while ensuring a consistent and streamlined experience when building Falco plugins.\nC++ SDK The C++ SDK provides abstract base classes for plugin development. Plugin authors can derive from these base classes and implement abstract methods to:\nSupply plugin metadata and capabilities. Provide events. Extract fields from events. Go SDK We offer a Go SDK that simplifies plugin development by providing support code and abstractions. This SDK includes:\nGo structs and enums corresponding to the C structs and enums used by the plugin API. Utility packages to handle memory management and type conversions. Abstract interfaces that provide a streamlined and user-friendly way to implement plugins. For a detailed explanation of the architecture and usage of the Go SDK, refer to the Go SDK walkthrough section.\nRust SDK We recently introduced a Rust SDK, enabling developers to write plugins in Rust. The Rust SDK offers a safe, idiomatic interface for interacting with the Falco plugin API while leveraging Rust’s strong type system and memory safety guarantees.\n","summary":"","tags":null,"title":"Plugins SDKs","url":"https://v0-43--falcosecurity.netlify.app/docs/developer-guide/plugins/sdks/"},{"category":"docs","content":"Install Falco First, ensure you have a Linux machine with a recent version of Docker installed. Note that the following will not work on Windows or macOS running Docker Desktop.\nRun the following command:\ndocker run --rm -it \\ --name falco \\ --privileged \\ -v /sys/kernel/tracing:/sys/kernel/tracing:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /proc:/host/proc:ro \\ -v /etc:/host/etc:ro \\ falcosecurity/falco:0.43.0 Falco is now monitoring your system using the pre-installed set of rules that alert you upon suspicious behavior.\nTrigger a rule Open another terminal on the same machine and run:\nsudo cat /etc/shadow Now go back to Falco, and you'll see a message like:\n2024-06-21T08:54:23.812791015+0000: Warning Sensitive file opened for reading by non-trusted program (file=/etc/shadow gparent=sudo ggparent=bash gggparent=tmux: evt_type=openat user=root user_uid=0 user_loginuid=1000 process=cat proc_exepath=/usr/bin/cat parent=sudo command=cat /etc/shadow terminal=34826 container_id=host container_name=host) This is your first Falco event 🦅! If you are curious, this is the rule that describes it.\nCreate a custom rule Now it's time to create our own rule and load it into Falco. We can be pretty creative with them, but let's stick with something simple. This time, we want to be alerted when any file is opened for writing in the /etc directory, either on the host or inside containers.\nStop the Falco container with Ctrl-C, copy the following text in a file and call it falco_custom_rules.yaml:\n- rule: Write below etc desc: An attempt to write to /etc directory condition: \u0026gt; (evt.type in (open,openat,openat2) and evt.is_open_write=true and fd.typechar=\u0026#39;f\u0026#39; and fd.num\u0026gt;=0) and fd.name startswith /etc output: \u0026#34;File below /etc opened for writing | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty\u0026#34; priority: WARNING tags: [filesystem, mitre_persistence] Then start Falco again, this time mounting the new rule file:\ndocker run --rm -it \\ --name falco \\ --privileged \\ -v /sys/kernel/tracing:/sys/kernel/tracing:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /proc:/host/proc:ro \\ -v /etc:/host/etc:ro \\ -v $(pwd)/falco_custom_rules.yaml:/etc/falco/falco_rules.local.yaml \\ falcosecurity/falco:0.43.0 Finally, open another terminal and write a file in /etc:\nsudo touch /etc/test_file_falco_rule You should see an alert in the Falco terminal, just as before. As you can see, a lot of contextual information is displayed, as it was specified in the output field of the rule. There are many such fields that you can use both in the condition and the output to build your rule.\n","summary":"","tags":null,"title":"Try Falco with Docker","url":"https://v0-43--falcosecurity.netlify.app/docs/getting-started/falco-docker-quickstart/"},{"category":"docs","content":"A Falco rule can contain the following keys:\n\u0026lt;table\u0026gt; Key Required Description Default rule yes A short, unique name for the rule. condition yes A filtering expression that is applied against events to check whether they match the rule. desc yes A longer description of what the rule detects. output yes Specifies the message that should be output if a matching event occurs. See output. priority yes A case-insensitive representation of the severity of the event. Should be one of the following: emergency, alert, critical, error, warning, notice, informational, debug. exceptions no A set of exceptions that cause the rule to not generate an alert. enabled no If set to false, a rule is neither loaded nor matched against any events. true tags no A list of tags applied to the rule (more on this below). warn_evttypes no If set to false, Falco suppresses warnings related to a rule not having an event type (more on this below). true skip-if-unknown-filter no If set to true, if a rule conditions contains a filtercheck, e.g. fd.some_new_field, that is not known to this version of Falco, Falco silently accepts the rule but does not execute it; if set to false, Falco reports an error and exists when finding an unknown filtercheck. false source no The event source for which this rule should be evaluated. Typical values are syscall, k8s_audit, or the source advertised by a source plugin. syscall append no When set to true, it adds conditions and/or exceptions to a previously defined rule or macro instead of overseeding it. Not used when the goal is just to enable an already existing rule. In case of appending to a list, it adds new elements to it. ","summary":"","tags":null,"title":"Rule fields","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/rules/rule-fields/"},{"category":"docs","content":"","summary":"","tags":null,"title":"Glossary","url":"https://v0-43--falcosecurity.netlify.app/docs/reference/glossary/"},{"category":"docs","content":"Action Items (TL;DR) Read Install and Operate Guides and review falco.yaml and any local configuration file for necessary preconditions. Address common startup issues by verifying and correcting config misconceptions. Monitor for potential kernel driver bugs, though less frequent. Be aware of userspace bugs that can also interfere with Falco startup. First, always try running Falco with the default and/or easiest configuration without any plugins. Let's find out!\nDebugging Tips Please acknowledge that The Falco Project performs a wide range of tests and provides pre-built kernel drivers, but perfection is not guaranteed.\nHow do I determine if Falco does not start up because of a kernel driver or userspace or pure config issue?\nWhen you start Falco, watch the print statements. If Falco crashes after passing load config stages, especially during syscall source setup, it signals potential kernel driver issues. These issues may include device unavailability, permission problems, or strange printouts. Alternatively, it could suggest that the kernel driver is not present in the first place, for instance, due to a download failure or missing mounts. If Falco started up, but then crashed after, it's likely a genuine bug somewhere, we would have to find out. Kernel Drivers Falco kernel driver issues are the most common source of frustrating errors. Please note that since Falco 0.38.0, modern_ebpf driver is the new default driver, and it will be automatically used wherever is supported; this should help mitigate most of the following issues. Here are a few tips to demystify what can go wrong with respect to Falco's kernel drivers:\nCheck if all preconditions to start up the kernel drivers are met. Common issues include: For ebpf based drivers, the bpf syscall needs to be allowed and not blocked by SELinux or similar. Ensure the DKMS package is installed for the kmod driver, and your system may require custom-signed kernel modules. Also, verify the availability of the host /dev mount (e.g. /dev:/host/dev when running Falco over a container). In general, check that Falco has all host mounts when running from a container or as a daemonset in Kubernetes. Critical mounts for running Falco, assuming the kernel driver is available, include: /etc:/host/etc, /proc:/host/proc, /boot:/host/boot, /dev:/host/dev. For ebpf and kmod drivers, the kernel object code needs to be available for the exact kernel release (uname -r) of your system. This invites a wide range of possible issues: If you use the Falco open source binary on Linux distributions such as stock Ubuntu, Fedora, Debian, Arch Linux, Oracle Linux, Rocky Linux, AlmaLinux, etc., you may encounter an issue if the pre-built kernel driver from The Falco Project is not available for download. Verify on the Driver Index page if the driver is available for your specific OS and kernel. Your network ACLs may be blocking the download. In case the download fails, building the driver on the fly (over the init container in Kubernetes, for example) can fail for many reasons. Lastly, if you run a custom kernel, you'll need to build your own drivers (ebpf or kmod only) or explore the option of using the modern_ebpf driver if applicable. If your kernel version is \u0026gt;= 5.8 and you are enforcing either kmod or ebpf driver, consider switching to the modern_ebpf driver. It's bundled into the userspace binary and works out of the box, regardless of the kernel release, thanks to the eBPF feature called 'Compile Once Run Everywhere' (CO-RE). If you are using the ebpf or modern_ebpf driver and encounter verbose and lengthy instruction printouts, you may have encountered a dreaded eBPF verifier failure. In such cases, kindly reach out to the Falco maintainers, providing the kernel release (uname -r). Resolving such instances involves modifying the driver code to ensure the eBPF verifier is happy again. Userspace Errors associated with Falco's rules or configurations are generally more understandable, and we provide warnings with clear instructions. Historically, we have encountered edge case bugs with some newer features. Please bear with us in such cases, and we typically release patches to address them. In the past, there have been instances where regressions were introduced, and certain configurations or combinations thereof may exhibit unexpected behavior. However, Falco's core functionality undergoes comprehensive testing, and we are committed to ensuring its continued reliability. Restarts Falco is a C/C++ application for performance reasons, and as such, it is not unheard of for Falco to crash and restart in some rare code paths or edge case conditions. However, if you deploy Falco with resource limits, for example the OOM killer can also kill the process and force a restart. Read more in the Falco Performance Guide.\nReferences and Community Discussions [UMBRELLA] Errors at Falco start-up related to Falco's kernel driver {kmod, ebpf, modern_ebpf} Falco Performance Driver Index ","summary":"","tags":null,"title":"Falco Is Not Starting Up","url":"https://v0-43--falcosecurity.netlify.app/docs/troubleshooting/start-up-error/"},{"category":"docs","content":"Introduction This section explains how to develop a plugin from scratch with the official Go SDK.\nWe'll create a plugin for the docker events from a local docker daemon. It is a basic example of an event stream with a basic format and without specific authentication.\nTo know more about the available feature of the Go SDK and how to see use, you can refer to this page.\nAwaited result At the end, your plugin will allow you to get that kind of alerts:\n2022-02-08T10:58:56.370816183+01:00 container create e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6 (image=alpine, name=confident_kirch) 2022-02-08T10:58:56.371818906+01:00 container attach e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6 (image=alpine, name=confident_kirch) 2022-02-08T10:58:56.482094215+01:00 network connect 5864a44bccca4e0963dfe9c3087919bf8f8e5c3aa7db33dd6d9ae7138c5ee3f3 (container=e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6, name=bridge, type=bridge) 2022-02-08T10:58:56.804166856+01:00 container start e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6 (image=alpine, name=confident_kirch) 2022-02-08T10:58:56.831912702+01:00 container die e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6 (exitCode=0, image=alpine, name=confident_kirch) 2022-02-08T10:58:57.072125878+01:00 network disconnect 5864a44bccca4e0963dfe9c3087919bf8f8e5c3aa7db33dd6d9ae7138c5ee3f3 (container=e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6, name=bridge, type=bridge) 2022-02-08T10:58:57.132390363+01:00 container destroy e327f1fa52a90d79421e416aed60e6de6872231f31101a1cc63401e90cef4bd6 (image=alpine, name=confident_kirch) The Docker SDK For reducing the complexity to communicate with the docker daemon, we'll use the official docker sdk.\nRequirements The only requirements for this examples are:\na docker daemon running in your local system falco \u0026gt;=0.35 installed in your local system go \u0026gt;= 1.19 Code Organization To simplify contributions and keep a consistency between plugins, we propose a specific organization for the repositories of plugins:\n. ├── LICENSE ├── Makefile ├── README.md ├── ├── go.mod ├── go.sum ├── pkg │ └── docker.go ├── plugin │ └── main.go └── rules └── docker_rules.yaml The directories:\npkg: Contains all modules for our plugin, we use a pkg folder because they might be imported and used by other plugins. plugin: Contains the main.go of our plugin. rules: Contains one or more .yaml files with default rules for the plugin. The files:\nLICENSE: The license file, most of the plugins are under Apache License 2.0. README: The README, see in the repository for an example. Makefile: Allows to easily build and install the plugin, see in the repository for an example. falco.yaml: (optional) An example file with the minimal configuration to use the plugin. rules/docker_rules.yaml: An example rule file, its name must respect \u0026lt;plugin_name\u0026gt;_rules.yaml. go.mod, go.sum: Classic go module files. The plugin codebase plugin/main.go This is the entrypoint of our plugin.\nThis is where we declare the details of our plugin:\npackage main import ( docker \u0026#34;github.com/Issif/docker-plugin/pkg\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/extractor\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/source\u0026#34; ) const ( PluginID uint32 = 5 PluginName = \u0026#34;docker\u0026#34; PluginDescription = \u0026#34;Docker Events\u0026#34; PluginContact = \u0026#34;github.com/falcosecurity/plugins/\u0026#34; PluginVersion = \u0026#34;0.2.0\u0026#34; PluginEventSource = \u0026#34;docker\u0026#34; ) func init() { plugins.SetFactory(func() plugins.Plugin { p := \u0026amp;docker.Plugin{} p.SetInfo( PluginID, PluginName, PluginDescription, PluginContact, PluginVersion, PluginEventSource, ) extractor.Register(p) source.Register(p) return p }) } func main() {} Few requirements:\nPluginID (Sourcing Capability Only) The ID field is mandatory and must be unique in the registry across all the plugins with event source capability PluginName: The name field is mandatory and must be unique across all the plugins in the registry. The plugin name must match this regular expression: ^[a-z]+[a-z0-9-_\\-]*$ (however, its not recommended to use _ in the name, unless you are trying to match the name of a source or for particular reasons) PluginEventSource: The source (Sourcing Capability Only) and sources (Extraction Capability Only) must match this regular expression: ^[a-z]+[a-z0-9_]*$ The imports Despite basic Go modules, we'll have to import the different plugin-sdk-go modules (\u0026gt;= 0.5.0) and other modules we need for our plugin:\nimport ( docker \u0026#34;github.com/Issif/docker-plugin/pkg\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/extractor\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/source\u0026#34; ) We'll import these different components of plugin-sdk-go in almost every plugin we'll write. They're really convenient and provide a much easier way to deal with the Falco plugin framework.\nThe const const ( ID uint32 = 5 Name = \u0026#34;docker\u0026#34; Description = \u0026#34;Docker Events\u0026#34; Contact = \u0026#34;github.com/Issif/docker-plugin\u0026#34; Version = \u0026#34;0.2.0\u0026#34; EventSource = \u0026#34;docker\u0026#34; ) The const are used to declare all mandatory information of our plugin through the docker.SetInfo() method:\nID: Must be unique among all plugins, it's used by the framework in captures to know which plugin is the source of events. It's also important for avoiding collisions if you want to share your plugin in the registry, see the main repository for more details. Name: The name of our plugin, will be used in plugins section of falco.yaml. The plugin name must match this regular expression: ^[a-z]+[a-z0-9-_\\-]*$ (however, its not recommended to use _ in the name, unless you are trying to match the name of a source or for particular reasons). Description: The description of our plugin. Contact: A contact link, often a link to the repository. Version: All plugins must be versioned for compatibility with Falco, the versioning must follow the semantic versioning. EventSource: This represents the value we'll set in Falco rules for mapping, in our case, all rules we'll set will have source: docker. The source must match this regular expression: ^[a-z]+[a-z0-9_]*$. The functions main() The main() function is mandatory for any go program, but because we'll build the plugin as a library for the Falco plugin framework which is written in C, we can let it empty.\n// main is mandatory but empty, because the plugin will be used as C library by Falco plugin framework func main() {} init() The init() function is used for registering our plugin to the Falco plugin framework, as a source and an extractor. We also use it to set the info of the plugin:\nfunc init() { plugins.SetFactory(func() plugins.Plugin { p := \u0026amp;docker.Plugin{} p.SetInfo( ID, Name, Description, Contact, Version, EventSource, ) extractor.Register(p) source.Register(p) return p }) } The init() contains also some specific functions and methods:\nplugins.SetFactory() is a method to register our plugin to the framework SetInfo() is a method to set the details of our plugin before it's registered to the Falco plugin framework source.Register() allows to declare our plugin as a source to the framework, ie, a plugin to collect events from a source extractor.Register() allows to declare our plugin as an extractor to the framework, ie, a plugin to extract fields from an event pkg/docker.go The module used by our main.go, it can also be imported by other plugins, especially when it's an extractor.\npackage docker import ( \u0026#34;context\u0026#34; \u0026#34;encoding/json\u0026#34; \u0026#34;fmt\u0026#34; \u0026#34;io\u0026#34; \u0026#34;io/ioutil\u0026#34; \u0026#34;github.com/alecthomas/jsonschema\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/source\u0026#34; dockerTypes \u0026#34;github.com/docker/docker/api/types\u0026#34; dockerEvents \u0026#34;github.com/docker/docker/api/types/events\u0026#34; docker \u0026#34;github.com/moby/docker/client\u0026#34; ) var ( ID uint32 Name string Description string Contact string Version string EventSource string ) type PluginConfig struct { FlushInterval uint64 `json:\u0026#34;flushInterval\u0026#34; jsonschema:\u0026#34;description=Flush Interval in ms (Default: 30)\u0026#34;` } // Plugin represents our plugin type Plugin struct { plugins.BasePlugin Config PluginConfig lastDockerEventMessage dockerEvents.Message lastDockerEventNum uint64 } // setDefault is used to set default values before mapping with InitSchema() func (p *PluginConfig) setDefault() { p.FlushInterval = 30 } // SetInfo is used to set the Info of the plugin func (p *Plugin) SetInfo(id uint32, name, description, contact, version, eventSource string) { ID = id Name = name Contact = contact Version = version EventSource = eventSource } // Info displays information of the plugin to Falco plugin framework func (p *Plugin) Info() *plugins.Info { return \u0026amp;plugins.Info{ ID: ID, Name: Name, Description: Description, Contact: Contact, Version: Version, EventSource: EventSource, } } // InitSchema map the configuration values with Plugin structure through JSONSchema tags func (p *Plugin) InitSchema() *sdk.SchemaInfo { reflector := jsonschema.Reflector{ RequiredFromJSONSchemaTags: true, // all properties are optional by default AllowAdditionalProperties: true, // unrecognized properties don\u0026#39;t cause a parsing failures } if schema, err := reflector.Reflect(\u0026amp;PluginConfig{}).MarshalJSON(); err == nil { return \u0026amp;sdk.SchemaInfo{ Schema: string(schema), } } return nil } // Init is called by the Falco plugin framework as first entry, // we use it for setting default configuration values and mapping // values from `init_config` (json format for this plugin) func (p *Plugin) Init(config string) error { p.Config.setDefault() return json.Unmarshal([]byte(config), \u0026amp;p.Config) } // Fields exposes to Falco plugin framework all availables fields for this plugin func (p *Plugin) Fields() []sdk.FieldEntry { return []sdk.FieldEntry{ {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.status\u0026#34;, Desc: \u0026#34;Status of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.id\u0026#34;, Desc: \u0026#34;ID of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.from\u0026#34;, Desc: \u0026#34;From of the event (deprecated)\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.type\u0026#34;, Desc: \u0026#34;Type of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.action\u0026#34;, Desc: \u0026#34;Action of the event\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.stack.namespace\u0026#34;, Desc: \u0026#34;Stack Namespace\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.id\u0026#34;, Desc: \u0026#34;Swarm Node ID\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.task\u0026#34;, Desc: \u0026#34;Swarm Task\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.taskid\u0026#34;, Desc: \u0026#34;Swarm Task ID\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.taskname\u0026#34;, Desc: \u0026#34;Swarm Task Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.servicename\u0026#34;, Desc: \u0026#34;Swarm Service Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.statenew\u0026#34;, Desc: \u0026#34;Node New State\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.stateold\u0026#34;, Desc: \u0026#34;Node Old State\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.container\u0026#34;, Desc: \u0026#34;Attribute Container\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.image\u0026#34;, Desc: \u0026#34;Attribute Image\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.name\u0026#34;, Desc: \u0026#34;Attribute Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.type\u0026#34;, Desc: \u0026#34;Attribute Type\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.exitcode\u0026#34;, Desc: \u0026#34;Attribute Exit Code\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.signal\u0026#34;, Desc: \u0026#34;Attribute Signal\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.scope\u0026#34;, Desc: \u0026#34;Scope\u0026#34;}, } } // Extract allows Falco plugin framework to get values for all available fields func (p *Plugin) Extract(req sdk.ExtractRequest, evt sdk.EventReader) error { msg := p.lastDockerEventMessage // For avoiding to Unmarshal the same message for each field to extract // we store it with its EventNum. When it\u0026#39;s a new event with a new message, we // update the Plugin struct. if evt.EventNum() != p.lastDockerEventNum { rawData, err := ioutil.ReadAll(evt.Reader()) if err != nil { fmt.Println(err.Error()) return err } err = json.Unmarshal(rawData, \u0026amp;msg) if err != nil { return err } p.lastDockerEventMessage = msg p.lastDockerEventNum = evt.EventNum() } switch req.Field() { case \u0026#34;docker.status\u0026#34;: req.SetValue(msg.Status) case \u0026#34;docker.id\u0026#34;: req.SetValue(msg.ID) case \u0026#34;docker.from\u0026#34;: req.SetValue(msg.From) case \u0026#34;docker.type\u0026#34;: req.SetValue(msg.Type) case \u0026#34;docker.action\u0026#34;: req.SetValue(msg.Action) case \u0026#34;docker.scope\u0026#34;: req.SetValue(msg.Scope) case \u0026#34;docker.actor.id\u0026#34;: req.SetValue(msg.Actor.ID) case \u0026#34;docker.stack.namespace\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.stack.namespace\u0026#34;]) case \u0026#34;docker.swarm.task\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task\u0026#34;]) case \u0026#34;docker.swarm.taskid\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task.id\u0026#34;]) case \u0026#34;docker.swarm.taskname\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task.name\u0026#34;]) case \u0026#34;docker.swarm.servicename\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.service.name\u0026#34;]) case \u0026#34;docker.node.id\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.node.id\u0026#34;]) case \u0026#34;docker.node.statenew\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;state.new\u0026#34;]) case \u0026#34;docker.node.stateold\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;state.old\u0026#34;]) case \u0026#34;docker.attributes.container\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;container\u0026#34;]) case \u0026#34;docker.attributes.image\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;image\u0026#34;]) case \u0026#34;docker.attributes.name\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;name\u0026#34;]) case \u0026#34;docker.attributes.type\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;type\u0026#34;]) default: return fmt.Errorf(\u0026#34;no known field: %s\u0026#34;, req.Field()) } return nil } // Open is called by Falco plugin framework for opening a stream of events, we call that an instance func (Plugin *Plugin) Open(params string) (source.Instance, error) { dclient, err := docker.NewClientWithOpts() if err != nil { return nil, err } eventC := make(chan source.PushEvent) ctx, cancel := context.WithCancel(context.Background()) // launch an async worker that listens for Docker events and pushes them // to the event channel go func() { defer close(eventC) msgC, errC := dclient.Events(ctx, dockerTypes.EventsOptions{}) var msg dockerEvents.Message var err error for { select { case msg = \u0026lt;-msgC: bytes, err := json.Marshal(msg) if err != nil { eventC \u0026lt;- source.PushEvent{Err: err} // errors are blocking, so we can stop here return } eventC \u0026lt;- source.PushEvent{Data: bytes} case err = \u0026lt;-errC: if err == io.EOF { // map EOF to sdk.ErrEOF, which is recognized by the Go SDK err = sdk.ErrEOF } eventC \u0026lt;- source.PushEvent{Err: err} // errors are blocking, so we can stop here return } } }() return source.NewPushInstance(eventC, source.WithInstanceClose(cancel)) } // String represents the raw value of on event // (not currently used by Falco plugin framework, only there for future usage) func (Plugin *Plugin) String(in io.ReadSeeker) (string, error) { evtBytes, err := ioutil.ReadAll(in) if err != nil { return \u0026#34;\u0026#34;, err } evtStr := string(evtBytes) return fmt.Sprintf(\u0026#34;%v\u0026#34;, evtStr), nil } The imports Despite basic Go modules, we'll have to import the different modules from plugin-sdk-go and from Docker SDK to docker events:\nimport ( \u0026#34;context\u0026#34; \u0026#34;encoding/json\u0026#34; \u0026#34;fmt\u0026#34; \u0026#34;io\u0026#34; \u0026#34;io/ioutil\u0026#34; \u0026#34;github.com/alecthomas/jsonschema\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins\u0026#34; \u0026#34;github.com/falcosecurity/plugin-sdk-go/pkg/sdk/plugins/source\u0026#34; dockerTypes \u0026#34;github.com/docker/docker/api/types\u0026#34; dockerEvents \u0026#34;github.com/docker/docker/api/types/events\u0026#34; docker \u0026#34;github.com/moby/docker/client\u0026#34; ) The global variables Global variables are declared and filled with the SetInfo() method called by the init() of the main.go. These variables are then used to declare the details of the plugin to Falco:\nvar ( ID uint32 Name string Description string Contact string Version string EventSource string ) The structures The structure to declare the plugin is mandatory and must respect the interface declared in the SDK:\ntype PluginConfig struct { FlushInterval uint64 `json:\u0026#34;flushInterval\u0026#34; jsonschema:\u0026#34;description=Flush Interval in ms (Default: 30)\u0026#34;` } // Plugin represents our plugin type Plugin struct { plugins.BasePlugin Config PluginConfig lastDockerEventMessage dockerEvents.Message lastDockerEventNum uint64 } Plugin represents our plugin that will be loaded by the framework. It contains some fields:\nplugins.BasePlugin: Allows to respect the Plugin interface of the SDK. Config: Contains the configuration of our plugin, represented by the PluginConfig structure. lastDockerEventMessage: Contains the result of the last unmarshalled event. lastDockerEventNum: Contains the number of the unmarshalled event, by comparing it, we avoid to unmarshal the same event several times. PluginConfig represents the configuration of our plugin, we'll use the module alecthomas/jsonschema to map the content of init_config from the plugin section of falco.yaml and check its validity:\nplugins: - name: docker library_path: /etc/falco/audit/libdocker.so init_config: \u0026#39;{\u0026#34;flushinterval\u0026#34;: 10}\u0026#39; open_params: \u0026#39;\u0026#39; The functions and methods SetInfo() It's used to set the global variables which represent the details of our plugin, this method is called by the init() of the main.go:\n// SetInfo is used to set the Info of the plugin func (p *Plugin) SetInfo(id uint32, name, description, contact, version, eventSource string) { ID = id Name = name Contact = contact Version = version EventSource = eventSource } Info() This method is mandatory and all plugins must respect that. It allows the Falco plugin framework to have all intel about the plugin itself, we use the global variables and the SetInfo() method to set the values:\n// Info displays information of the plugin to Falco plugin framework func (p *Plugin) Info() *plugins.Info { return \u0026amp;plugins.Info{ ID: ID, Name: Name, Description: Description, Contact: Contact, Version: Version, EventSource: EventSource, } } Init() This method (different from the function init()) will be the first one called by the Falco plugin framework, we use setDefault() to set the default values of the config. In our case, these default values are overridden by the values from init_config:.\n// Init is called by the Falco plugin framework as first entry, // we use it for setting default configuration values and mapping // values from `init_config` (json format for this plugin) func (p *Plugin) Init(config string) error { p.Config.setDefault() return json.Unmarshal([]byte(config), \u0026amp;p.Config) } InitSchema() InitSchema() and the jsonschema tags from the fields of PluginConfig struct are used to check the validity of the content of init_config from falco.yaml.\n// InitSchema map the configuration values with Plugin structure through JSONSchema tags func (p *Plugin) InitSchema() *sdk.SchemaInfo { reflector := jsonschema.Reflector{ RequiredFromJSONSchemaTags: true, // all properties are optional by default AllowAdditionalProperties: true, // unrecognized properties don\u0026#39;t cause a parsing failures } if schema, err := reflector.Reflect(\u0026amp;PluginConfig{}).MarshalJSON(); err == nil { return \u0026amp;sdk.SchemaInfo{ Schema: string(schema), } } return nil } It uses a json schema reflector, see jsonschema for more details about how it works.\nFields() This method declares to the Falco plugin framework all fields that will be available for the rules, with their names and their types.\n// Fields exposes to Falco plugin framework all availables fields for this plugin func (dockerPlugin *DockerPlugin) Fields() []sdk.FieldEntry { return []sdk.FieldEntry{ {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.status\u0026#34;, Desc: \u0026#34;Status\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.id\u0026#34;, Desc: \u0026#34;ID\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.from\u0026#34;, Desc: \u0026#34;From\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.type\u0026#34;, Desc: \u0026#34;Type\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.action\u0026#34;, Desc: \u0026#34;Action\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.stack.namespace\u0026#34;, Desc: \u0026#34;Stack Namespace\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.id\u0026#34;, Desc: \u0026#34;Swarm Node ID\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.task\u0026#34;, Desc: \u0026#34;Swarm Task\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.taskid\u0026#34;, Desc: \u0026#34;Swarm Task ID\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.taskname\u0026#34;, Desc: \u0026#34;Swarm Task Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.swarm.servicename\u0026#34;, Desc: \u0026#34;Swarm Service Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.statenew\u0026#34;, Desc: \u0026#34;Node New State\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.node.stateold\u0026#34;, Desc: \u0026#34;Node Old State\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.container\u0026#34;, Desc: \u0026#34;Attribute Container\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.image\u0026#34;, Desc: \u0026#34;Attribute Image\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.name\u0026#34;, Desc: \u0026#34;Attribute Name\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.type\u0026#34;, Desc: \u0026#34;Attribute Type\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.exitcode\u0026#34;, Desc: \u0026#34;Attribute Exit Code\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.attributes.signal\u0026#34;, Desc: \u0026#34;Attribute Signal\u0026#34;}, {Type: \u0026#34;string\u0026#34;, Name: \u0026#34;docker.scope\u0026#34;, Desc: \u0026#34;Scope\u0026#34;}, } } String() Even if this method is mandatory, it's not used by Falco for now but must be set up for future usage. It simply retrieves the events, it can be in JSON or any format as long it contains the whole content of the source event.\n// String represents the raw value of on event // (not currently used by Falco plugin framework, only there for future usage) func (dockerPlugin *DockerPlugin) String(in io.ReadSeeker) (string, error) { evtBytes, err := ioutil.ReadAll(in) if err != nil { return \u0026#34;\u0026#34;, err } evtStr := string(evtBytes) return fmt.Sprintf(\u0026#34;%v\u0026#34;, evtStr), nil } Extract() This method is called by the Falco plugin framework for getting the values of fields:\n// Extract allows Falco plugin framework to get values for all available fields func (p *Plugin) Extract(req sdk.ExtractRequest, evt sdk.EventReader) error { msg := p.lastDockerEventMessage // For avoiding to Unmarshal the same message for each field to extract // we store it with its EventNum. When it\u0026#39;s a new event with a new message, we // update the Plugin struct. if evt.EventNum() != p.lastDockerEventNum { rawData, err := ioutil.ReadAll(evt.Reader()) if err != nil { fmt.Println(err.Error()) return err } err = json.Unmarshal(rawData, \u0026amp;msg) if err != nil { return err } p.lastDockerEventMessage = msg p.lastDockerEventNum = evt.EventNum() } switch req.Field() { case \u0026#34;docker.status\u0026#34;: req.SetValue(msg.Status) case \u0026#34;docker.id\u0026#34;: req.SetValue(msg.ID) case \u0026#34;docker.from\u0026#34;: req.SetValue(msg.From) case \u0026#34;docker.type\u0026#34;: req.SetValue(msg.Type) case \u0026#34;docker.action\u0026#34;: req.SetValue(msg.Action) case \u0026#34;docker.scope\u0026#34;: req.SetValue(msg.Scope) case \u0026#34;docker.actor.id\u0026#34;: req.SetValue(msg.Actor.ID) case \u0026#34;docker.stack.namespace\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.stack.namespace\u0026#34;]) case \u0026#34;docker.swarm.task\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task\u0026#34;]) case \u0026#34;docker.swarm.taskid\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task.id\u0026#34;]) case \u0026#34;docker.swarm.taskname\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.task.name\u0026#34;]) case \u0026#34;docker.swarm.servicename\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.service.name\u0026#34;]) case \u0026#34;docker.node.id\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;com.docker.swarm.node.id\u0026#34;]) case \u0026#34;docker.node.statenew\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;state.new\u0026#34;]) case \u0026#34;docker.node.stateold\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;state.old\u0026#34;]) case \u0026#34;docker.attributes.container\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;container\u0026#34;]) case \u0026#34;docker.attributes.image\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;image\u0026#34;]) case \u0026#34;docker.attributes.name\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;name\u0026#34;]) case \u0026#34;docker.attributes.type\u0026#34;: req.SetValue(msg.Actor.Attributes[\u0026#34;type\u0026#34;]) default: return fmt.Errorf(\u0026#34;no known field: %s\u0026#34;, req.Field()) } return nil } Try to not overlap the fields created by other plugins, for eg, in this example we can use docker. prefix because Falco libs use container. fields which are more generic, so we've not a conflict.\nFor this plugin, we use the modules provided by the Docker SDK, all retrieved events will be unmarshaled into the events.Message struct which simplifies the mapping and the extraction of fields.\nTo avoid to unmarshall for each field extraction the same message and impact the performances, we store the number (=~ event ID) and the result of the last unmarshalled message. When the number change, it means it's not the same event and we can unmarshall its message and store it with its number.\nmsg := p.lastDockerEventMessage // For avoiding to Unmarshal the same message for each field to extract // we store it with its EventNum. When it\u0026#39;s a new event with a new message, we // update the Plugin struct. if evt.EventNum() != p.lastDockerEventNum { rawData, err := ioutil.ReadAll(evt.Reader()) if err != nil { fmt.Println(err.Error()) return err } err = json.Unmarshal(rawData, \u0026amp;msg) if err != nil { return err } p.lastDockerEventMessage = msg p.lastDockerEventNum = evt.EventNum() } Open() This methods is used by the Falco plugin framework for opening a new stream of events, what is called an instance (source.Instance). The current implementation creates only one instance per plugin but it's possible in future that same plugin allows to open several streams, and so several instances at once.\nTo simplify the creation of this source.Instance, the Go SDK provides two easy functions, see the docs:\nsource.NewPullInstance: for when the event source can be implemented sequentially and the time required to generate a sequence of event is deterministic, eg: periodic calls to an external API source.NewPushInstance: for when the event source can be suspensive and there is no time guarantee regarding when an event gets produced, eg: we wait a webhook from an external service For collecting events from docker, we'll use source.NewPushInstance as the docker SDK creates a channel and sends the events into when they happened.\n// Open is called by Falco plugin framework for opening a stream of events, we call that an instance func (Plugin *Plugin) Open(params string) (source.Instance, error) { dclient, err := docker.NewClientWithOpts() if err != nil { return nil, err } eventC := make(chan source.PushEvent) ctx, cancel := context.WithCancel(context.Background()) // launch an async worker that listens for Docker events and pushes them // to the event channel go func() { defer close(eventC) msgC, errC := dclient.Events(ctx, dockerTypes.EventsOptions{}) var msg dockerEvents.Message var err error for { select { case msg = \u0026lt;-msgC: bytes, err := json.Marshal(msg) if err != nil { eventC \u0026lt;- source.PushEvent{Err: err} // errors are blocking, so we can stop here return } eventC \u0026lt;- source.PushEvent{Data: bytes} case err = \u0026lt;-errC: if err == io.EOF { // map EOF to sdk.ErrEOF, which is recognized by the Go SDK err = sdk.ErrEOF } eventC \u0026lt;- source.PushEvent{Err: err} // errors are blocking, so we can stop here return } } }() return source.NewPushInstance(eventC, source.WithInstanceClose(cancel)) } We'll not describe with details the docker relative part, see the documentation of the Docker SDK for more info. You just have to know it creates a channel to receive the events from the engine and we use same context than the whole plugin.\nHere's the most important things to notice:\neventC := make(chan source.PushEvent): we create a channel, it will be used by the instance to listen incoming events, we'll push into it the events from the docker client ctx, cancel := context.WithCancel(context.Background()): we create a context, and more important, a Done channel for this context eventC \u0026lt;- source.PushEvent{Data: bytes}: this is how to push an event to the instance return source.NewPushInstance(eventC, source.WithInstanceClose(cancel)): the Open() method must return a source.Instance, and source.NewPushInstance() requires a channel where the events will pushed and may have optional settings, in our case, we pass also the Done channel of the context with the source.WithInstanceClose() function Passing to the instance the same Done channel than the docker client uses, allows to correctly stop the plugin when we ask Falco to stop (CTRL+C or systemctl stop falco).\nBuild the plugin The plugin is built as a c-shared library, it means a .so:\ngo build -buildmode=c-shared -o libdocker.so If you use make from the repository:\nmake build Installation The plugins are commonly installed in /usr/share/falco/plugins, just move the libdocker.so you built or run make install.\nMakefile To simplify the build and the installation of the plugin, we can use a Makefile like this one:\nSHELL=/bin/bash -o pipefail GO ?= go NAME := docker OUTPUT := lib$(NAME).so DESTDIR := /usr/share/falco/plugins ifeq ($(DEBUG), 1) GODEBUGFLAGS= GODEBUG=cgocheck=2 else GODEBUGFLAGS= GODEBUG=cgocheck=0 endif all: build clean: @rm -f lib$(NAME).so build: clean @$(GODEBUGFLAGS) $(GO) build -buildmode=c-shared -buildvcs=false -o $(OUTPUT) ./plugin install: build mv $(OUTPUT) $(DESTDIR)/ This makefile will work for any plugin, just change the NAME variable.\nConfiguration Now we have our plugin, we must declare it to Falco in falco.yaml:\nplugins: - name: docker library_path: /usr/share/falco/plugins/libdocker.so init_config: \u0026#39;{\u0026#34;flushinterval\u0026#34;: 1}\u0026#39; load_plugins: [docker] stdout_output: enabled: true For more details about this configuration, see how to load and configure a plugin.\nRules We create a simple rule, for checking that the fields and source work as expected:\n- rule: Container status changed desc: Container status changed condition: docker.status in (create,start,die) output: status=%docker.status from=%docker.from type=%docker.type action=%docker.action name=%docker.attributes.name priority: DEBUG source: docker tags: [docker] Test and Results Let's run Falco with our configuration and rules files:\nfalco -c falco.yaml -r rules/docker_rules.yaml 17:17:24.008405000: Debug status=create from=alpine type=container action=create name=bold_keller 17:17:24.008953000: Debug status=start from=alpine type=container action=start name=bold_keller 17:17:24.009076000: Debug status=die from=alpine type=container action=die name=bold_keller Events detected: 3 Rule counts by severity: DEBUG: 3 Triggered rules by rule name: Container status changed: 3 Syscall event drop monitoring: - event drop detected: 0 occurrences - num times actions taken: 0 It works!\n","summary":"","tags":null,"title":"How to develop a plugin","url":"https://v0-43--falcosecurity.netlify.app/docs/developer-guide/plugins/how-to-develop/"},{"category":"docs","content":" The Falco Operator is now the recommended way to deploy Falco on Kubernetes. It provides a declarative, Kubernetes-native experience with Custom Resources for managing Falco instances, rules, plugins, and configuration. The Helm chart method described on this page remains fully supported.\nFalco consumes streams of events and evaluates them against a set of security rules to detect abnormal behavior. By default, Falco is pre-configured to consume events from the Linux Kernel. This default installation scenario will add Falco to all nodes in your cluster using a DaemonSet. This scenario requires Falco to be privileged, and depending on the kernel version installed on the node, a driver will be installed on the node.\nFor other installation scenarios, such as consuming cloud events or other data sources using plugins, please refer to the Plugins section.\nA well-established method to deploy Falco on a Kubernetes cluster is to use the provided Helm chart. The official Falco charts repository is hosted at:\nhttps://falcosecurity.github.io/charts If needed, you can consult the Installing Helm guide for information about how to download and install Helm. Before deploying Falco on Kubernetes, ensure you can access the targeted cluster running with Linux nodes, either x86_64 or ARM64. Also, you will need to have kubectl and helm installed and configured.\nAlternatively, Falco can be installed in Kubernetes without Helm by providing manifest files and deploying them to your cluster. For details, see the example here.\nInstall First, add the Helm repository:\nhelm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update Then install Falco:\nhelm install --replace falco --namespace falco --create-namespace --set tty=true falcosecurity/falco And check that the Falco pods are running:\nkubectl get pods -n falco Falco pod(s) might need a few seconds to start. Wait until they are ready:\nkubectl wait pods --for=condition=Ready --all -n falco Configuration When deploying Falco via Helm, you will use Helm values to pass the Falco configuration. For further details, see the Falco Helm Chart documentation.\nUpgrade If you wish to upgrade Falco to a new version, you need to find the corresponding version in the Falco Helm Chart repository (e.g., 4.8.1 is for Falco 0.38.2) then run:\nhelm upgrade falco -n falco --version 4.8.1 To avoid any possible disruption, before upgrading to a new version, consult the Falco Helm chart Breaking Changes page.\nUninstall If you wish to remove Falco from your cluster, you can simply run:\nhelm uninstall falco -n falco ","summary":"","tags":null,"title":"Deploy on Kubernetes with Helm","url":"https://v0-43--falcosecurity.netlify.app/docs/setup/kubernetes/"},{"category":"docs","content":" The gRPC Output as well as the embedded gRPC server have been deprecated in Falco 0.43.0 and will be removed in a future release. Until removal and since Falco 0.43.0, using any of them will result in a warning informing the user about the deprecation. Users are encouraged to leverage another output and/or Falcosidekick, as the usage will result in an error after the removal.\nEnabling the Server The Falco gRPC server and the Falco gRPC Outputs APIs are not enabled by default.\nTo enable them, edit the falco.yaml Falco configuration file. A sample Falco configuration file is given below:\n# Falco supports running a gRPC server with two main binding types # 1. Over the network with mandatory mutual TLS authentication (mTLS) # 2. Over a local unix socket with no authentication # By default, the gRPC server is disabled, with no enabled services (see grpc_output) # please comment/uncomment and change accordingly the options below to configure it. # Important note: if Falco has any troubles creating the gRPC server # this information will be logged, however the main Falco daemon will not be stopped. # gRPC server over network with (mandatory) mutual TLS configuration. # This gRPC server is secure by default so you need to generate certificates and update their paths here. # By default the gRPC server is off. # You can configure the address to bind and expose it. # By modifying the threadiness configuration you can fine-tune the number of threads (and context) it will use. grpc: enabled: true bind_address: \u0026#34;0.0.0.0:5060\u0026#34; threadiness: 8 private_key: \u0026#34;/etc/falco/certs/server.key\u0026#34; cert_chain: \u0026#34;/etc/falco/certs/server.crt\u0026#34; root_certs: \u0026#34;/etc/falco/certs/ca.crt\u0026#34; As you can see, binding to a network address requires you to generate and specify a set of TLS certificates as shown in the next section.\nAlternatively, if you want something simpler, you can tell Falco to bind the gRPC server to a local unix socket, this does not require you to generate certificates for mTLS but also comes without any authentication mechanism.\n# gRPC server using an unix socket grpc: enabled: true bind_address: \u0026#34;unix:///run/falco/falco.sock\u0026#34; threadiness: 8 Then, remember to enable the services you need. Otherwise, the gRPC server won't expose anything.\nFor the outputs use:\n# gRPC output service. # By default it is off. # By enabling this all the output events will be kept in memory until you read them with a gRPC client. # Make sure to have a consumer for them or leave this disabled. grpc_output: enabled: true Certificates When configured to bind to a network address, the Falco gRPC server works only with mutual TLS by design. Therefore, you have to generate the certificates and update the paths in the above configuration.\nThe Falco authors plan to automate the certificate generation soon.\nIn the meantime, use the following script to generate the certificates.\nNote: Ensure that you configure the -passin, -passout, and -subj flags according to your settings.\nGenerate CA Run the following commands:\n$ openssl genrsa -des3 -passout pass:1234 -out ca.key 4096 $ openssl req -new \\ -x509 \\ -days 365 \\ -key ca.key \\ -out ca.crt \\ -passin pass:1234 \\ -subj \u0026#34;/C=SP/ST=Italy/L=Ornavasso/O=Test/OU=Test/CN=Root CA\u0026#34; Generate Server Key/Cert Run the following command:\n$ openssl genrsa -des3 -passout pass:1234 -out server.key 4096 $ openssl req -new \\ -key server.key \\ -out server.csr \\ -passin pass:1234 \\ -subj \u0026#34;/C=SP/ST=Italy/L=Ornavasso/O=Test/OU=Server/CN=localhost\u0026#34; $ openssl x509 -req \\ -days 365 \\ -CA ca.crt \\ -CAkey ca.key \\ -in server.csr \\ -out server.crt \\ -set_serial 01 \\ -passin pass:1234 Remove passphrase from Server Key Run the following command:\n$ openssl rsa -in server.key -out server.key -passin pass:1234 Generate Client Key/Cert Run the following command:\n$ openssl genrsa -des3 -passout pass:1234 -out client.key 4096 $ openssl req -new \\ -passin pass:1234 \\ -key client.key \\ -out client.csr \\ -subj \u0026#34;/C=SP/ST=Italy/L=Ornavasso/O=Test/OU=Client/CN=localhost\u0026#34; $ openssl x509 -req \\ -days 365 \\ -CA ca.crt \\ -CAkey ca.key \\ -set_serial 01 \\ -in client.csr \\ -out client.crt \\ -passin pass:1234 Remove passphrase from Client Key Run the following command:\n$ openssl rsa -in client.key -out client.key -passin pass:1234 Usage When the configuration is complete, Falco is ready to expose its gRPC server and its Outputs APIs.\nTo do so, simply run Falco. For example:\n$ falco -c falco.yaml -r rules/falco_rules.yaml -r rules/falco_rules.local.yaml Refer to the Go client documentation to learn how to receive and consume Falco output events.\n","summary":"","tags":null,"title":"Configuration","url":"https://v0-43--falcosecurity.netlify.app/docs/developer-guide/grpc/grpc-config/"},{"category":"docs","content":"Standard Output When configured to send alerts via standard output, a line is printed for each alert.\nHere is an example:\nstdout_output: enabled: true 10:20:05.408091526: Warning Sensitive file opened for reading by non-trusted program (user=root command=cat /etc/shadow file=/etc/shadow) Standard output is useful when using Fluentd or Logstash to capture logs from containers. Alerts can then be stored in Elasticsearch, and dashboards can be created to visualize the alerts. For more information, read this blog post.\nStandard Output buffering If the logs are inspected by tailing container logs (e.g. kubectl logs -f in Kubernetes) it might look like events can take a long time to appear, sometimes longer than 15 minutes. This is not an issue with Falco but is simply a side effect of the system output buffering.\nHowever, if realtime update of these logs is necessary it can be forced with the -U/--unbuffered command line option which will ensure the output is flushed for every event at the cost of higher CPU usage.\nFile Output When configured to send alerts to a file, a message is written to the file for each alert. The configuration is very similar to the Standard Output format:\nfile_output: enabled: true keep_alive: false filename: ./events.txt When the field keep_alive is set to false (default value), for each single alert:\nthe file is opened for appending the single alert is written the file is closed If keep_alive is set to true, the file is opened before the first alert, and kept open for all subsequent alerts. Output is buffered and will be flushed only on close. (This can be changed with the --unbuffered command line option).\nNotice that, regardless keep_alive settings, Falco neither rotates nor truncates the output file. If you'd like to use a program like logrotate to rotate the output file, an example logrotate config is available here.\nAs of Falco 0.10.0, Falco will close and reopen its file output when signaled with SIGUSR1. The logrotate example above depends on it.\nSyslog Output When configured to send alerts to syslog, a syslog message is sent for each alert. The actual format depends on your syslog daemon, but here's a simple configuration example:\nsyslog_output: enabled: true And its respective entry in the syslog service:\nJun 7 10:20:05 ubuntu falco: Sensitive file opened for reading by non-trusted program (user=root command=cat /etc/shadow file=/etc/shadow) Syslog messages are sent with a facility of \u0026lt;strong\u0026gt;\u0026lt;code\u0026gt;LOG_USER\u0026lt;/code\u0026gt;\u0026lt;/strong\u0026gt;.\u0026lt;br\u0026gt; The rule's priority is used as the priority of the syslog message.\nProgram Output When configured to send alerts to a program, Falco normally starts the program for each alert and writes its contents to the program's standard input. You can only configure a single program output (e.g. route alerts to a single program) at a time.\nHere you can find an example of how to configure the program_output inside the falco.yaml file:\nprogram_output: enabled: true keep_alive: false program: mail -s \u0026#34;Falco Notification\u0026#34; someone@example.com If the program cannot normally accept an input from standard input, xargs can be used to pass the Falco events with an argument. For example:\nprogram_output: enabled: true keep_alive: false program: \u0026#34;xargs -I {} aws --region ${region} sns publish --topic-arn ${falco_sns_arn} --message {}\u0026#34; When keep_alive is set to false (default value), for each alert Falco will run the program mail -s ... and write the alert to the program. The program is run via a shell, so it's possible to specify a command pipeline if you wish to add additional formatting.\nIf keep_alive is set to true, before the first alert Falco will spawn the program and write the alert. The program pipe will be kept open for subsequent alerts. Output is buffered and will be flushed only on close. (This can be changed with the --unbuffered command line option).\nControlling the program output The program spawned by Falco is in the same process group as Falco and will receive all signals that Falco receives. If you want to, say, ignore \u0026lt;code\u0026gt;SIGTERM\u0026lt;/code\u0026gt; to allow for a clean shutdown in the face of buffered outputs, you must override the signal handler yourself. As of Falco 0.10.0, Falco will close and reopen its file output when signaled with SIGUSR1. Example 1: Posting to a Slack Incoming Webhook If you'd like to send Falco notifications to a slack channel, here's the required configuration to massage the JSON output to a form required for the slack webhook endpoint:\n# Whether to output events in json or text json_output: true … program_output: enabled: true program: \u0026#34;jq \u0026#39;{text: .output}\u0026#39; | curl -d @- -X POST https://hooks.slack.com/services/XXX\u0026#34; Example 2: Sending Alerts to Network Channel If you'd like to send a stream of alerts over a network connection, here's an example:\n# Whether to output events in json or text json_output: true … program_output: enabled: true keep_alive: true program: \u0026#34;nc host.example.com 1234\u0026#34; Note the use of keep_alive: true to keep the network connection persistent.\nHTTP/HTTPS Output If you'd like to send alerts to an HTTP(S) endpoint, you can use the http_output option:\njson_output: true ... http_output: enabled: true url: http://some.url/some/path/ Currently, only unencrypted HTTP endpoints and valid HTTPS endpoints are supported (i.e., invalid or self-signed certificates are not supported).\nJSON Output For all output channels, you can switch to JSON output either in the configuration file or on the command line. For each alert, Falco will print a JSON object, on a single line, containing the following properties:\ntime: the time of the alert, in ISO8601 format. rule: the rule that resulted in the alert. priority: the priority of the rule that generated the alert. output: the formatted output string for the alert. hostname: the name of the host running Falco (can be the hostname inside the container). tags: the list of tags associated with the rule. output_fields: for each templated value in the output expression, the value of that field from the event that triggered the alert. Notice that, besides the ones included automatically, you can also include additional fields to output_fields through append_output settings in the configuration.\nHere's an example:\n{\u0026#34;hostname\u0026#34;:\u0026#34;falco-xczjd\u0026#34;,\u0026#34;output\u0026#34;:\u0026#34;13:44:05.478445995: Critical A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=kubecon container=ee97d9c4186f shell=sh parent=runc cmdline=sh -c clear; (bash || ash || sh) terminal=34816 container_id=ee97d9c4186f image=docker.io/library/alpine)\u0026#34;,\u0026#34;priority\u0026#34;:\u0026#34;Critical\u0026#34;,\u0026#34;rule\u0026#34;:\u0026#34;Terminal shell in container\u0026#34;,\u0026#34;source\u0026#34;:\u0026#34;syscall\u0026#34;,\u0026#34;tags\u0026#34;:[\u0026#34;container\u0026#34;,\u0026#34;mitre_execution\u0026#34;,\u0026#34;shell\u0026#34;],\u0026#34;time\u0026#34;:\u0026#34;2023-05-25T13:44:05.478445995Z\u0026#34;, \u0026#34;output_fields\u0026#34;: {\u0026#34;container.id\u0026#34;:\u0026#34;ee97d9c4186f\u0026#34;,\u0026#34;container.image.repository\u0026#34;:\u0026#34;docker.io/library/alpine\u0026#34;,\u0026#34;evt.time\u0026#34;:1685022245478445995,\u0026#34;k8s.ns.name\u0026#34;:\u0026#34;default\u0026#34;,\u0026#34;k8s.pod.name\u0026#34;:\u0026#34;kubecon\u0026#34;,\u0026#34;proc.cmdline\u0026#34;:\u0026#34;sh -c clear; (bash || ash || sh)\u0026#34;,\u0026#34;proc.name\u0026#34;:\u0026#34;sh\u0026#34;,\u0026#34;proc.pname\u0026#34;:\u0026#34;runc\u0026#34;,\u0026#34;proc.tty\u0026#34;:34816,\u0026#34;user.loginuid\u0026#34;:-1,\u0026#34;user.name\u0026#34;:\u0026#34;root\u0026#34;}} Here's the same output, pretty-printed:\n{ \u0026#34;hostname\u0026#34;: \u0026#34;falco-xczjd\u0026#34;, \u0026#34;output\u0026#34;: \u0026#34;13:44:05.478445995: Critical A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=kubecon container=ee97d9c4186f shell=sh parent=runc cmdline=sh -c clear; (bash || ash || sh) terminal=34816 container_id=ee97d9c4186f image=docker.io/library/alpine)\u0026#34;, \u0026#34;priority\u0026#34;: \u0026#34;Critical\u0026#34;, \u0026#34;rule\u0026#34;: \u0026#34;Terminal shell in container\u0026#34;, \u0026#34;source\u0026#34;: \u0026#34;syscall\u0026#34;, \u0026#34;tags\u0026#34;: [ \u0026#34;container\u0026#34;, \u0026#34;mitre_execution\u0026#34;, \u0026#34;shell\u0026#34; ], \u0026#34;time\u0026#34;: \u0026#34;2023-05-25T13:44:05.478445995Z\u0026#34;, \u0026#34;output_fields\u0026#34;: { \u0026#34;container.id\u0026#34;: \u0026#34;ee97d9c4186f\u0026#34;, \u0026#34;container.image.repository\u0026#34;: \u0026#34;docker.io/library/alpine\u0026#34;, \u0026#34;evt.time\u0026#34;: 1685022245478445995, \u0026#34;k8s.ns.name\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;k8s.pod.name\u0026#34;: \u0026#34;kubecon\u0026#34;, \u0026#34;proc.cmdline\u0026#34;: \u0026#34;sh -c clear; (bash || ash || sh)\u0026#34;, \u0026#34;proc.name\u0026#34;: \u0026#34;sh\u0026#34;, \u0026#34;proc.pname\u0026#34;: \u0026#34;runc\u0026#34;, \u0026#34;proc.tty\u0026#34;: 34816, \u0026#34;user.loginuid\u0026#34;: -1, \u0026#34;user.name\u0026#34;: \u0026#34;root\u0026#34; } } gRPC Output The gRPC Output as well as the embedded gRPC server have been deprecated in Falco 0.43.0 and will be removed in a future release. Until removal and since Falco 0.43.0, using any of them will result in a warning informing the user about the deprecation. Users are encouraged to leverage another output and/or Falcosidekick, as the usage will result in an error after the removal.\nIf you'd like to send alerts to an external program connected via gRPC API, you need to enable both the grpc and grpc_output options as described under the gRPC Configuration section.\n","summary":"","tags":null,"title":"Output Channels","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/outputs/channels/"},{"category":"docs","content":"Welcome to the guide on how to build Falco yourself! You are very brave! Since you are already doing all this, chances that you are willing to contribute are high! Please read our contributing guide.\nInstall the dependencies CentOS / RHEL \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#dependencies-1\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;dependencies-1\u0026quot;\u0026gt;Debian/ Ubuntu\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#dependencies-2\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;dependencies-2\u0026quot;\u0026gt;Arch Linux\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#dependencies-3\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;dependencies-3\u0026quot;\u0026gt;Alpine\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#dependencies-4\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;dependencies-4\u0026quot;\u0026gt;openSUSE\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt;\u0026lt;/ul\u0026gt; \u0026lt;div class=\u0026quot;tab-content\u0026quot; id=\u0026quot;dependencies\u0026quot;\u0026gt;\u0026lt;div id=\u0026quot;dependencies-0\u0026quot; class=\u0026quot;tab-pane show active\u0026quot; role=\u0026quot;tabpanel\u0026quot; aria-labelledby=\u0026quot;dependencies-0\u0026quot;\u0026gt; \u0026lt;p\u0026gt;\u0026lt;p\u0026gt;CentOS 8 Stream / RHEL 8\u0026lt;/p\u0026gt; dnf install git gcc gcc-c++ make cmake elfutils-libelf-devel perl-IPC-Cmd \u0026lt;p\u0026gt;\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-bash\u0026quot; data-lang=\u0026quot;bash\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;apt update \u0026lt;span style=\u0026quot;color:#666\u0026quot;\u0026gt;\u0026amp;amp;\u0026amp;amp;\u0026lt;/span\u0026gt; apt install git cmake clang build-essential linux-tools-common linux-tools-generic libelf-dev bpftool \u0026lt;p\u0026gt;\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-bash\u0026quot; data-lang=\u0026quot;bash\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;pacman -S git cmake make gcc wget pacman -S zlib jq yaml-cpp openssl curl c-ares protobuf grpc libyaml bpf You'll also need kernel headers for building and making binaries properly.\npacman -S linux-headers You can use uname -r to determine the kernel version and select the appropriate header.\n\u0026lt;p\u0026gt;\u0026lt;p\u0026gt;Since Alpine ships with \u0026lt;code\u0026gt;musl\u0026lt;/code\u0026gt; instead of \u0026lt;code\u0026gt;glibc\u0026lt;/code\u0026gt;, to build on Alpine, we need to pass the \u0026lt;code\u0026gt;-DMUSL_OPTIMIZED_BUILD=On\u0026lt;/code\u0026gt; CMake option.\u0026lt;/p\u0026gt; If that option is used along with the -DUSE_BUNDLED_DEPS=On option, then the final build will be 100% statically-linked and portable across different Linux distributions.\napk add g++ gcc cmake make git bash perl linux-headers autoconf automake m4 libtool elfutils-dev libelf-static binutils bpftool clang \u0026lt;p\u0026gt;\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-bash\u0026quot; data-lang=\u0026quot;bash\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;zypper -n install git gcc12 gcc12-c++ cmake make libelf-devel gawk Build Falco CentOS / RHEL \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#build-1\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;build-1\u0026quot;\u0026gt;Debian/ Ubuntu\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#build-2\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;build-2\u0026quot;\u0026gt;Arch Linux\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#build-3\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;build-3\u0026quot;\u0026gt;Alpine\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#build-4\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;build-4\u0026quot;\u0026gt;openSUSE\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt;\u0026lt;/ul\u0026gt; \u0026lt;div class=\u0026quot;tab-content\u0026quot; id=\u0026quot;build\u0026quot;\u0026gt;\u0026lt;div id=\u0026quot;build-0\u0026quot; class=\u0026quot;tab-pane show active\u0026quot; role=\u0026quot;tabpanel\u0026quot; aria-labelledby=\u0026quot;build-0\u0026quot;\u0026gt; \u0026lt;p\u0026gt;\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-bash\u0026quot; data-lang=\u0026quot;bash\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;git clone https://github.com/falcosecurity/falco.git cd falco mkdir -p build cd build cmake -DUSE_BUNDLED_DEPS=ON .. make falco More details here.\n\u0026lt;p\u0026gt;\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-bash\u0026quot; data-lang=\u0026quot;bash\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;git clone https://github.com/falcosecurity/falco.git cd falco mkdir -p build cd build cmake -DUSE_BUNDLED_DEPS=On .. make falco More details here.\n\u0026lt;p\u0026gt;\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-bash\u0026quot; data-lang=\u0026quot;bash\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;git clone https://github.com/falcosecurity/falco.git cd falco mkdir -p build cd build cmake .. make falco More details here.\n\u0026lt;p\u0026gt;\u0026lt;div class=\u0026quot;highlight\u0026quot;\u0026gt;\u0026lt;pre tabindex=\u0026quot;0\u0026quot; style=\u0026quot;background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\u0026quot;\u0026gt;\u0026lt;code class=\u0026quot;language-bash\u0026quot; data-lang=\u0026quot;bash\u0026quot;\u0026gt;\u0026lt;span style=\u0026quot;display:flex;\u0026quot;\u0026gt;\u0026lt;span\u0026gt;git clone https://github.com/falcosecurity/falco.git cd falco mkdir -p build cd build cmake -DUSE_BUNDLED_DEPS=On -DMUSL_OPTIMIZED_BUILD=On .. make falco \u0026lt;p\u0026gt;\u0026lt;p\u0026gt;First, make sure that \u0026lt;code\u0026gt;gcc\u0026lt;/code\u0026gt; and \u0026lt;code\u0026gt;g++\u0026lt;/code\u0026gt; are version 9 or above. If you have multiple versions installed you can \u0026lt;a href=\u0026quot;/docs/developer-guide/source/#specify-c-and-cxx-compilers\u0026quot;\u0026gt;set the preferred one\u0026lt;/a\u0026gt;.\u0026lt;/p\u0026gt; git clone https://github.com/falcosecurity/falco.git cd falco mkdir -p build cd build cmake -DUSE_BUNDLED_DEPS=ON .. make falco More details here.\nBuild kernel module driver CentOS / RHEL \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#kernelmodule-1\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;kernelmodule-1\u0026quot;\u0026gt;Debian/ Ubuntu\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#kernelmodule-2\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;kernelmodule-2\u0026quot;\u0026gt;Arch Linux\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#kernelmodule-3\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;kernelmodule-3\u0026quot;\u0026gt;Alpine\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#kernelmodule-4\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;kernelmodule-4\u0026quot;\u0026gt;openSUSE\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt;\u0026lt;/ul\u0026gt; \u0026lt;div class=\u0026quot;tab-content\u0026quot; id=\u0026quot;kernelmodule\u0026quot;\u0026gt;\u0026lt;div id=\u0026quot;kernelmodule-0\u0026quot; class=\u0026quot;tab-pane show active\u0026quot; role=\u0026quot;tabpanel\u0026quot; aria-labelledby=\u0026quot;kernelmodule-0\u0026quot;\u0026gt; \u0026lt;p\u0026gt;\u0026lt;p\u0026gt;In the build directory:\u0026lt;/p\u0026gt; yum -y install kernel-devel-$(uname -r) make driver More details here.\n\u0026lt;p\u0026gt;\u0026lt;p\u0026gt;Kernel headers are required to build the driver.\u0026lt;/p\u0026gt; apt install linux-headers-$(uname -r) In the build directory:\nmake driver \u0026lt;p\u0026gt;\u0026lt;p\u0026gt;In the build directory:\u0026lt;/p\u0026gt; pacman -S --needed linux-headers make driver More details here.\n\u0026lt;p\u0026gt;\u0026lt;p\u0026gt;NO STEP\u0026lt;/p\u0026gt; \u0026lt;p\u0026gt;\u0026lt;p\u0026gt;In the build directory:\u0026lt;/p\u0026gt; zypper -n install kernel-default-devel make driver Build eBPF driver (deprecated) CentOS / RHEL \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#ebpfdriver-1\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;ebpfdriver-1\u0026quot;\u0026gt;Debian/ Ubuntu\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#ebpfdriver-2\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;ebpfdriver-2\u0026quot;\u0026gt;Arch Linux\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#ebpfdriver-3\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;ebpfdriver-3\u0026quot;\u0026gt;Alpine\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; \u0026lt;li class=\u0026quot;nav-item\u0026quot;\u0026gt;\u0026lt;a data-toggle=\u0026quot;tab\u0026quot; class=\u0026quot;nav-link\u0026quot; href=\u0026quot;#ebpfdriver-4\u0026quot; role=\u0026quot;tab\u0026quot; aria-controls=\u0026quot;ebpfdriver-4\u0026quot;\u0026gt;openSUSE\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt;\u0026lt;/ul\u0026gt; \u0026lt;div class=\u0026quot;tab-content\u0026quot; id=\u0026quot;ebpfdriver\u0026quot;\u0026gt;\u0026lt;div id=\u0026quot;ebpfdriver-0\u0026quot; class=\u0026quot;tab-pane show active\u0026quot; role=\u0026quot;tabpanel\u0026quot; aria-labelledby=\u0026quot;ebpfdriver-0\u0026quot;\u0026gt; \u0026lt;p\u0026gt;\u0026lt;p\u0026gt;If you do not want to use the kernel module driver you can, alternatively, build the eBPF driver as follows.\u0026lt;/p\u0026gt; In the build directory:\ndnf install clang llvm cmake -DBUILD_BPF=ON .. make bpf \u0026lt;p\u0026gt;\u0026lt;p\u0026gt;If you do not want to use the kernel module driver you can, alternatively, build the eBPF driver as follows.\u0026lt;/p\u0026gt; In the build directory:\napt install llvm clang cmake -DBUILD_BPF=ON .. make bpf \u0026lt;p\u0026gt;\u0026lt;p\u0026gt;If you do not want to use the kernel module driver you can, alternatively, build the eBPF driver as follows.\u0026lt;/p\u0026gt; In the build directory:\npacman -S llvm clang cmake -DBUILD_BPF=ON .. make bpf \u0026lt;p\u0026gt;\u0026lt;p\u0026gt;NO STEP\u0026lt;/p\u0026gt; \u0026lt;p\u0026gt;\u0026lt;p\u0026gt;If you do not want to use the kernel module driver you can, alternatively, build the eBPF driver as follows.\u0026lt;/p\u0026gt; In the build directory:\nzypper -n install clang llvm cmake -DBUILD_BPF=ON .. make bpf Dependencies By default Falco build bundles most of its runtime dependencies dynamically.\nYou can notice this observing that the option USE_BUNDLED_DEPS is OFF by default. Which means that, whether applicable, Falco build will try to link against libraries already existing into your machine.\nChanging such option to ON causes Falco build to bundle all the dependencies statically.\nBuild Falco To build Falco, you will need to create a build directory. It's common to have the build directory in the Falco working copy itself, however it can be anywhere in your filesystem.\nThere are three main steps to compile Falco.\nCreate the build directory and enter in it Use cmake in the build directory to create the build files for Falco. .. was used because the source directory is a parent of the current directory, you can also use the absolute path for the Falco source code instead Build using make Build all mkdir build cd build cmake .. make You can also build only specific targets:\nBuild Falco only Do the build folder and cmake setup, then:\nmake falco Build the Falco engine only Do the build folder and cmake setup, then:\nmake falco_engine Build libscap only Do the build folder and cmake setup, then:\nmake scap Build libsinsp only Do the build folder and cmake setup, then:\nmake sinsp Build the eBPF probe / kernel driver only Do the build folder and cmake setup, then:\nmake driver Build results Once Falco is built, the three interesting things that you will find in your build folder are:\nuserspace/falco/falco: the actual Falco binary driver/src/falco.ko: the Falco kernel driver driver/bpf/falco.o: if you built Falco with eBPF support If you'd like to build a debug version, run cmake as cmake -DCMAKE_BUILD_TYPE=Debug .. instead, see the CMake Options section for further customizations.\nCMake Options When doing the cmake command, we can pass additional parameters to change the behavior of the build files.\nHere'are some examples, always assuming your build folder is inside the Falco working copy.\nGenerate verbose makefiles -DCMAKE_VERBOSE_MAKEFILE=On Specify C and CXX compilers -DCMAKE_C_COMPILER=$(which gcc) -DCMAKE_CXX_COMPILER=$(which g++) Enforce bundled dependencies -DUSE_BUNDLED_DEPS=True Read more about Falco dependencies here.\nTreat warnings as errors -DBUILD_WARNINGS_AS_ERRORS=True Specify the build type Debug build type\n-DCMAKE_BUILD_TYPE=Debug Release build type\n-DCMAKE_BUILD_TYPE=Release Notice this variable is case-insensitive and it defaults to release.\nSpecify the Falco version Optionally the user can specify the version he wants Falco to have. Eg.,\n-DFALCO_VERSION=0.43.0-dirty When not explicitly specifying it the build system will compute the FALCO_VERSION value from the git history.\nIn case the current git revision has a git tag, the Falco version will be equal to it (without the leading \u0026quot;v\u0026quot; character). Otherwise the Falco version will be in the form 0.\u0026lt;commit hash\u0026gt;[.dirty].\nEnable eBPF support -DBUILD_BPF=True When enabling this you will be able to make the bpf target after:\nmake bpf Load latest falco kernel module If you have a binary version of Falco installed, an older Falco kernel module may already be loaded. To ensure you are using the latest version, you should unload any existing Falco kernel module and load the locally built version.\nUnload any existing kernel module via:\nrmmod falco To load the locally built version, assuming you are in the build dir, use:\ninsmod driver/falco.ko Run falco Once Falco is built and the kernel module is loaded, assuming you are in the build dir, you can run falco as:\nsudo ./userspace/falco/falco -c ../falco.yaml -r ../rules/falco_rules.yaml By default, falco logs events to standard error.\n","summary":"","tags":null,"title":"Build Falco from source","url":"https://v0-43--falcosecurity.netlify.app/docs/developer-guide/source/"},{"category":"docs","content":"Rules A rule is a YAML object, part of the rules file, whose definition contains at least the following fields:\n- rule: shell_in_container desc: notice shell activity within a container condition: \u0026gt; (evt.type in (execve, execveat)) and container.id != host and (proc.name = bash or proc.name = ksh) output: \u0026gt; shell in a container | user=%user.name container_id=%container.id container_name=%container.name shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline priority: WARNING Conditions The key part of a rule is the condition field. A condition is a Boolean predicate expressed using the condition syntax. It is possible to express conditions on all supported events using their respective supported fields.\nHere's an example of a condition that alerts whenever a bash shell is run inside a container:\ncontainer.id != host and proc.name = bash The first clause checks that the event happened in a container (where container.id is not equal to \u0026quot;host\u0026quot; as the event occurs in a container). The second clause checks that the process name is bash.\nSince this condition does not include a clause with a system call it will only check event metadata.\u0026lt;br\u0026gt; Because of that, if a bash shell does start up in a container, Falco outputs events for every syscall that is performed by that shell.\nIf you want to be alerted only for each successful spawn of a shell in a container, add the appropriate event types to the condition:\n(evt.type in (execve, execveat)) and container.id != host and proc.name = bash Therefore, a complete rule using the above condition might be:\n- rule: shell_in_container desc: notice shell activity within a container condition: \u0026gt; (evt.type in (execve, execveat)) and container.id != host and proc.name = bash output: \u0026gt; shell in a container | user=%user.name container_id=%container.id container_name=%container.name shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline priority: WARNING Conditions allow you to check for many aspects of each supported event.\u0026lt;br\u0026gt; To learn more, see the condition language.\nOutput A rule output is a string that can use the same fields that conditions can use prepended by % to perform interpolation, akin to printf. For example:\nDisallowed SSH Connection (command=%proc.cmdline connection=%fd.name user=%user.name user_loginuid=%user.loginuid container_id=%container.id image=%container.image.repository) could output:\nDisallowed SSH Connection (command=sshd connection=127.0.0.1:34705-\u0026gt;10.0.0.120:22 user=root user_loginuid=-1 container_id=host image=\u0026lt;NA\u0026gt;) Outputs are usually written in a single line.\nModifying this output we try to present it to you in a more human-readable way.\nNote that it's not necessary that all fields are set in the specific event. As you can see in the example above if the connection happens outside a container the field %container.image.repository would not be set and \u0026lt;NA\u0026gt; is displayed instead.\nOutputs can also use the transform operators that are used in conditions. For example:\nDisallowed SSH Connection (command=%proc.cmdline connection=%fd.name user=%toupper(user.name) user_loginuid=%user.loginuid container_id=%toupper(container.id) image=%container.image.repository) could output:\nDisallowed SSH Connection (command=sshd connection=127.0.0.1:34705-\u0026gt;10.0.0.120:22 user=ROOT user_loginuid=-1 container_id=HOST image=\u0026lt;NA\u0026gt;) To learn more about how Falco processes the output and related settings, see the output formatting page.\nPriority Don't let the \u0026lt;strong\u0026gt;\u0026lt;code\u0026gt;priority\u0026lt;/code\u0026gt;\u0026lt;/strong\u0026gt; field name mislead you.\u0026lt;br\u0026gt; In a Falco Rule, it has nothing to do with overriding another rule or choosing the order in which rules will be triggered. The way to control the latter is achieved by changing the order the rules are defined and therefore loaded.\nEvery Falco rule has a priority which indicates how serious a violation of the rule is. This is similar to what we know as the severity of a syslog message. The priority is included in the message/JSON output/etc.\nHere are the available priorities:\nEMERGENCY ALERT CRITICAL ERROR WARNING NOTICE INFORMATIONAL DEBUG The general guidelines used to assign priorities to rules are the following:\nIf a rule is related to writing state (i.e. filesystem, etc.), its priority is ERROR. If a rule is related to an unauthorized read of state (i.e. reading sensitive files, etc.), its priority is WARNING. If a rule is related to unexpected behavior (spawning an unexpected shell in a container, opening an unexpected network connection, etc.), its priority is NOTICE. If a rule is related to behaving against good practices (unexpected privileged containers, containers with sensitive mounts, running interactive commands as root), its priority is INFO. One exception is that the rule \u0026amp;quot;Run shell untrusted\u0026amp;quot;, which is fairly FP-prone, has a priority of \u0026lt;code\u0026gt;DEBUG\u0026lt;/code\u0026gt;. Advanced Rule Syntax A Falco rule can contain several of the following keys:\nKey Required Description Default rule yes A short, unique name for the rule. condition yes A filtering expression that is applied against events to check whether they match the rule. desc yes A longer description of what the rule detects. output yes Specifies the message that should be output if a matching event occurs. See output. priority yes A case-insensitive representation of the severity of the event. Should be one of the following: emergency, alert, critical, error, warning, notice, informational, debug. exceptions no A set of exceptions that cause the rule to not generate an alert. enabled no If set to false, a rule is neither loaded nor matched against any events. true tags no A list of tags applied to the rule (more on this here). warn_evttypes no If set to false, Falco suppresses warnings related to a rule not having an event type (more on this here). true skip-if-unknown-filter no If set to true, if a rule conditions contains a filtercheck, e.g. fd.some_new_field, that is not known to this version of Falco, Falco silently accepts the rule but does not execute it; if set to false, Falco reports an error and exits when finding an unknown filtercheck. false source no The event source for which this rule should be evaluated. Typical values are syscall, k8s_audit, or the source advertised by a source plugin. syscall Macros Macros provide a way to define common sub-portions of rules in a reusable way.\nBy looking at the condition above it looks like both evt.type in (execve, execveat) and container.id != host would be used by many other rules, so to make our job easier we can easily define macros for both:\n- macro: container condition: (container.id != host) - macro: spawned_process condition: (evt.type in (execve, execveat)) With these macros defined, we can then rewrite the above rule's condition as spawned_process and container and proc.name = bash.\n- rule: shell_in_container desc: notice shell activity within a container condition: \u0026gt; spawned_process and container and proc.name = bash output: \u0026gt; shell in a container | user=%user.name container_id=%container.id container_name=%container.name shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline priority: WARNING For more examples of rules and macros, take a look the documentation on default macros and the rules/falco_rules.yaml file. In fact, both the macros above are part of the default list!\nMacros \u0026lt;em\u0026gt;can\u0026lt;/em\u0026gt; contain other macros that had been \u0026lt;strong\u0026gt;previously\u0026lt;/strong\u0026gt; defined. Lists Lists are named collections of items that you can include in rules, macros, or even other lists.\nPlease note that lists \u0026lt;em\u0026gt;cannot\u0026lt;/em\u0026gt; be parsed as filtering expressions. Each list node has the following keys:\nKey Description list The unique name for the list (as a slug) items The list of values Here are some example lists as well as a macro that uses them:\n- list: shell_binaries items: [bash, csh, ksh, sh, tcsh, zsh, dash] - list: userexec_binaries items: [sudo, su] - list: known_binaries items: [shell_binaries, userexec_binaries] - macro: safe_procs condition: proc.name in (known_binaries) Lists \u0026lt;em\u0026gt;can\u0026lt;/em\u0026gt; contain other lists that had been \u0026lt;strong\u0026gt;previously\u0026lt;/strong\u0026gt; defined. Referring to a list inserts the list items in the macro, rule, or list. Therefore, our rule could become more general replacing proc.name = bash with proc.name in (shell_binaries), or even better, using the already included macro shell_procs:\n- list: shell_binaries items: [bash, csh, ksh, sh, tcsh, zsh, dash] - macro: shell_procs condition: proc.name in (shell_binaries) - rule: shell_in_container desc: notice shell activity within a container condition: \u0026gt; spawned_process and container and shell_procs output: \u0026gt; shell in a container | user=%user.name container_id=%container.id container_name=%container.name shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline priority: WARNING Visibility As mentioned above, lists can reference other lists, and macros can reference other macros. The only requirement is that to reference an object of the same kind (a list including another list, or a macro including another macro) they must have been defined previously.\nHowever, if a macro included a list, this list might have been defined earlier or be defined at a later stage in the rules files. The same happens with a rule referencing a macro. This one doesn't need to be previously defined.\nIn other words, visibility is defined in cascade and is quite important:\nA list can only reference lists defined before it. A macro can only reference macros defined before it. A macro can reference any list. A rule can reference any macro. The same load-order principle applies across multiple rules files. See Overriding Rules for details on how the order of rules files affects appending and overriding existing lists, macros, and rules.\n","summary":"","tags":null,"title":"Basic Elements of Falco Rules","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/rules/basic-elements/"},{"category":"docs","content":"Overview Plugins are dynamic shared libraries (.so files in Unix, .dll files in Windows) that export C calling convention functions. Programs like Falco dynamically load these libraries and call the exported functions to extend Falco's support for event sources/fields.\nPlugins are versioned using semantic versioning to minimize regressions and compatibility issues.\nPlugins can be written in any language, as long as they export the required functions. Go, however, is the preferred language to write plugins, followed by C/C++.\nPlugins can implement one or more capabilities. In the scope of plugins, a capability is an extension of Falco's features in the form of a specific set of C function symbols exported by shared libraries. Currently, there are four plugin capabilities supported by the framework: event sourcing, field extraction, event parsing and async event\nPlugins are Coresident with Falco The libraries will do everything possible to validate the data coming from the plugins and protect Falco and the other consumers from corrupted data. However, for performance reasons, plugins are \u0026quot;trusted\u0026quot;: they run in the same thread and address space as Falco and they could crash the program. We assume that the user will be in control of plugin loading and will make sure only trusted plugins are loaded/packaged with Falco.\nPlugin SDKs To make it easier to write plugins, there are Go, C++, and Rust SDKs that handle the details of memory management and type conversion. These SDKs provide a streamlined way to implement plugins without having to deal with all the details of the lower-level functions that make up the Plugin API.\nThese SDKs are optional, but using them is highly recommended.\nEvent Sourcing Capability Plugins with event sourcing capability provide a new event source and make it available to libscap and libsinsp. They have the ability to \u0026quot;open\u0026quot; and \u0026quot;close\u0026quot; a stream of events and return those events to the plugin framework. They also provide a plugin ID, which is globally unique and is used in capture files (see below). Event sources provided by plugins with this capability are tied to the events they generate and can be used by plugins with field extraction capabilities and within Falco rules (see below).\nField Extraction Capability Plugins with field extraction capability have the ability to extract information from events based on fields. For example, a field (e.g. proc.name) extracts a value (e.g. process name like nginx) from a syscall event. The plugin returns a set of supported fields, and there are functions to extract a value given an event and field. The plugin framework can then build filtering expressions (e.g. rule conditions) based on these fields combined with relational and/or logical operators. For example, given the expression ct.name=root and ct.region=us-east-1, the plugin framework handles parsing the expression, calling the plugin to extract values for fields ct.name/ct.region for a given event, and determining the result of the expression. In a Falco output string like An EC2 Node was created (name=%ct.name region=%ct.region), the plugin framework handles parsing the output string, calling the plugin to extract values for fields, and building the resolved string, replacing the template field names (e.g. %ct.region) with values (e.g. us-east-1).\nPlugins with this capability only focus on field extraction from events generated by other plugins or by the core libraries. They do not provide an event source but can extract fields from other event sources. The supported field extraction can be generic or be tied to a specific event source. An example is json field extraction, where a plugin might be able to extract fields from generic json payloads.\nEvent Parsing Capability Plugins with event parsing capability can hook into an event stream and receive all of its events sequentially. The parsing phase is the stage in the event processing loop in which the Falcosecurity libraries inspect the content of the events' payload and use it to apply internal state updates or implement additional logic. This phase happens before any field extraction for a given event. Each event in a given stream is guaranteed to be received at most once.\nAsync Events Capability Plugins with async events capability can enrich an event stream from a given source (not necessarily implemented by itself) by injecting events asynchronously in the stream. Such a feature can be used for implementing notification systems or recording state transitions in the event-driven model of the Falcosecurity libraries, so that they can be available to other components at runtime or when the event stream is replayed through a capture file.\nFor example, the Falcosecurity libraries leverage this feature internally to implement metadata enrichment systems such as the one relative to container runtimes. In that case, the libraries implement asynchronous jobs responsible of retrieving such information externally outside of the main event processing loop so that it's non-blocking. The worker jobs produce a notification event every time a new container is detected and inject it asynchronously in the system event stream to be later processed for state updates and for evaluating Falco rules.\nComposability of Capabilities Plugin capabilities are composable, meaning that a single plugin can implement one or more capabilities. At loading time, the framework is able to recognize which capabilities the plugin correctly implements, and uses it accordingly inside Falco and the libraries. There can be plugins implementing event sourcing only, field extraction only, or both. For example, the AWS CloudTrail plugin implements both capabilities in order to provide the framework with the aws_cloudtrail event source and to allow extracting fields such as ct.name from the events it produces.\nPlugin Event IDs Every plugin with event sourcing capability requires its own, unique plugin event ID to interoperate with Falco and the other plugins. This ID is used in the following ways:\nThe ID is saved in in-memory event objects and is used to identify the associated plugin that injected the event. The ID is saved in capture files and is used to recreate in-memory event objects when reading capture files. The ID must be unique to ensure that events written by a given plugin will be properly associated with that plugin (and its event sources, see below).\nPlugin authors must register the plugin with the Falcosecurity organization by creating a PR to modify the plugin registry with details on the new plugin. This ensures that a given ID is used by exactly one plugin.\nPlugin Event Sources and Interoperability Events returned by plugins with event sourcing capability have an event source that describes the event's information. This is distinct from the plugin name to allow for multiple plugin implementations to generate the same kind of events. For example, there might be plugins gke-k8saudit, eks-k8saudit, ibmcloud-k8saudit, etc. that all fetch K8s Audit information. The plugins would have different names and IDs but would have the same event source k8s_audit.\nA plugin with field extraction capability optionally provides a set of compatible event sources. When the framework receives an event with an event source in the plugin's set of event sources, fields in expressions (i.e., fields included in the rule's output field) will be extracted from events using the plugin. The set of compatible event sources can also be omitted. In this case, all events will be presented to the plugin, regardless of their source. In this case, the plugin must detect the format of arbitrary payloads and be able to return NULL/no value when the payload is not supported. As such, given a specific event source such as k8s_audit, there is an implicit contract to honor regarding how data is formatted in each event of that source, such that compatible plugins with field extraction capability are able to parse events of a certain source even if they are produced by different plugins.\nPlugin authors should register the plugin with the Falcosecurity organization by creating a PR to modify the plugin registry file with details on the new plugin. This allows plugin authors to coordinate about event source data formats.\nHandling Duplicate/Overlapping Fields in Plugins/Libraries Core At an initial glance, adding plugins introduces the possibility of tens/hundreds of new filtercheck fields that could potentially overlap/conflict. For example, what happens if a plugin defines a proc.name field? However, the notion of event source makes these potential conflicts manageable.\nRemember that field extraction is always done in the context of an event, and each event can be mapped back to an event source. So we only need to ensure that filtercheck fields are non-overlapping for a given event source. For example, it's perfectly valid for an AWS CloudTrail plugin to define a proc.name field, as the events generated by that plugin are wholly separate from syscall events. For syscall events, the AWS CloudTrail plugin is not involved and the core libraries extract the process name for the tid performing a syscall. For AWS CloudTrail events, the core libraries are not involved in field extraction. Extraction is performed by the AWS CloudTrail plugin instead.\nWhen managing plugins, we only need to ensure the following:\nThat only one plugin is loaded at a time that exports a given event source. For example, the libraries can load either a gke-k8saudit plugin with event source k8s_audit, or eks-k8saudit with event source k8s_audit, but not both. That for a mix of plugins with event sourcing and field extraction capabilities having the same event source, that the fields are distinct. For example, a plugin event sourcing capability providing the source k8s_audit can export ka.* fields, and a plugin with field extractor capabilities with event source k8s_audit can export a jevt.value[/...] field, and the appropriate plugin will be used to extract fields from k8s_audit events as fields are parsed from condition expressions/output format strings. Plugin API Here is an overview of the functions that comprise the plugin API. This list is not extensive: the plugin API reference has full documentation of plugin APIs for all the capabilities supported by the framework.\nIn almost all cases, a plugin author can use the SDKs which provide a more streamlined interface. This still provides a good overview of the functionality a plugin provides.\nInfo Functions A set of functions provide information about the plugin and its compatibility with the plugin framework:\nplugin_get_required_api_version: Return the version of the plugin API used by a plugin. plugin_get_name: Return the name of the plugin. plugin_get_description: Return a short description of the plugin. plugin_get_contact: Return a contact url/email/twitter account for the plugin authors. plugin_get_version: Return the version of the plugin itself. plugin_get_last_error: Return the error that was last generated by a plugin. plugin_get_id: Return the unique ID of the plugin (event sourcing capability only). plugin_get_event_source: Return a string describing the events generated by a plugin (event sourcing capability only). plugin_get_async_events: Return a list of async events produced by a plugin (event parsing capability only). plugin_get_init_schema: (Optional) Return a string describing a schema for the configuration passed to plugin_init. plugin_list_open_params: (Optional) Return a list of suggested valid parameter values for plugin_open. plugin_get_extract_event_sources: (Optional) Return a list of all compatible event sources (field extraction capability only). plugin_get_extract_event_types: (Optional) Return a list of all compatible event types (field extraction capability only). plugin_get_parse_event_sources: (Optional) Return a list of all compatible event sources (event parsing capability only). plugin_get_parse_event_types: (Optional) Return a list of all compatible event types (event parsing capability only). plugin_get_async_event_sources: (Optional) Return a list of all compatible event sources (async events capability only). Instance/Capture Management Functions Plugins have functions to initialize/destroy a plugin, as well as functions to open/close streams of events:\nplugin_init: Initialize the plugin and, if needed, allocate its state. plugin_destroy: Destroy the plugin and, if plugin state was allocated, free it. plugin_open: Open the source and start a stream of events (event sourcing capability only). plugin_close: Close a stream of events (event sourcing capability only). Events/Fields Related Functions Plugins with event sourcing capability have functions to provide events to the plugin framework:\nplugin_next_batch: Return one or more events to the plugin framework. plugin_get_progress: (Optional) Provide feedback on how much of the event stream has been read. plugin_event_to_string: (Optional) Return a text representation of an event generated by a plugin. Plugins with field extraction capability have functions to define the set of fields that can be used to extract information from events, to actually extract values from events, and to return printable representations of events:\nplugin_get_fields: Return the list of extractor fields exported by a plugin. plugin_extract_fields: Extract one or more filter field values from an event. Other capabilities allow interacting with events for different scopes functionalities:\nplugin_parse_event: Parses an event at most once before the extraction phase, and can perform state updates. plugin_set_async_event_handler: Registers a callback that can be used to inject asynchronous events in an open event stream. ","summary":"","tags":null,"title":"Plugins Architecture Concepts","url":"https://v0-43--falcosecurity.netlify.app/docs/concepts/plugins/architecture/"},{"category":"docs","content":" The Falco Operator is the recommended way to deploy and manage Falco on Kubernetes. It provides a declarative, Kubernetes-native experience for managing Falco instances, detection rules, plugins, and configuration through Custom Resources.\nGoing forward, the Falco Operator will become the standard deployment method for Falco on Kubernetes. The existing Helm chart remains fully supported during the transition period.\nOverview The Falco Operator manages the full Falco ecosystem through Kubernetes Custom Resources:\nFalco Operator - Manages Falco instances (DaemonSet or Deployment mode) and ecosystem components Artifact Operator - Manages rules, plugins, and configuration fragments (runs as a sidecar in each Falco pod) The operator uses five Custom Resource Definitions (CRDs) across two API groups:\nCRD API Group Purpose Falco instance.falcosecurity.dev/v1alpha1 Define and manage a Falco instance Component instance.falcosecurity.dev/v1alpha1 Deploy ecosystem components (Falcosidekick, Falcosidekick UI, k8s-metacollector) Rulesfile artifact.falcosecurity.dev/v1alpha1 Manage detection rules (OCI, inline YAML, or ConfigMap) Plugin artifact.falcosecurity.dev/v1alpha1 Manage Falco plugins from OCI registries Config artifact.falcosecurity.dev/v1alpha1 Manage configuration fragments (inline YAML or ConfigMap) Prerequisites Kubernetes 1.29+ (native sidecar support required) kubectl installed and configured Cluster admin privileges (for CRD and ClusterRole installation) Install the Operator Install the Falco Operator with a single command:\nVERSION=latest if [ \u0026#34;$VERSION\u0026#34; = \u0026#34;latest\u0026#34; ]; then kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/latest/download/install.yaml else kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/download/${VERSION}/install.yaml fi This creates:\n5 CRDs The falco-operator namespace A ServiceAccount, ClusterRole, and ClusterRoleBinding The operator Deployment Verify the operator is running:\nkubectl get pods -n falco-operator kubectl wait pods --for=condition=Ready --all -n falco-operator Full Stack Quickstart Want to deploy the entire Falco ecosystem in one command? The quickstart manifest deploys everything in the falco namespace: Falco, detection rules, container and k8smeta plugins, Falcosidekick, Falcosidekick UI with Redis, k8s-metacollector, and the configuration to wire them all together:\nVERSION=latest if [ \u0026#34;$VERSION\u0026#34; = \u0026#34;latest\u0026#34; ]; then kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/latest/download/quickstart.yaml else kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/download/${VERSION}/quickstart.yaml fi Verify everything is running:\nkubectl get falco,plugins,rulesfiles,configs,components -n falco kubectl get pods -n falco All resources should show Reconciled: True and Available: True. All pods should be Running.\nTo uninstall (order matters - artifacts first so the sidecar can process finalizer cleanup):\n# 1. Artifacts first kubectl delete configs,rulesfiles,plugins --all -n falco # 2. Instances and components kubectl delete components,falcos --all -n falco # 3. Infrastructure kubectl delete statefulset falcosidekick-ui-redis -n falco kubectl delete svc falcosidekick-ui-redis -n falco # 4. Namespace kubectl delete namespace falco To configure Falcosidekick outputs (Slack, Elasticsearch, S3, etc.), see the Falcosidekick documentation.\nIf you prefer to deploy components individually and customize each one, follow the step-by-step quickstart below.\nStep-by-Step Quickstart Deploy Falco Create a Falco instance with default settings (DaemonSet mode, modern_ebpf driver):\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: instance.falcosecurity.dev/v1alpha1 kind: Falco metadata: name: falco spec: {} EOF Check that Falco pods are running on your nodes:\nkubectl get falco kubectl get pods -l app.kubernetes.io/name=falco Falco starts in idle mode until you provide detection rules. The next steps add the container plugin and rules to activate monitoring.\nAdd the Container Plugin The official Falco rules use fields like container.id and container.image.repository that require the container plugin. Without it, rules referencing container metadata fields will not work. Always load the container plugin before adding rules.\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: artifact.falcosecurity.dev/v1alpha1 kind: Plugin metadata: name: container spec: ociArtifact: image: repository: falcosecurity/plugins/plugin/container tag: latest registry: name: ghcr.io EOF Add Detection Rules Load the official Falco rules from the OCI registry:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: artifact.falcosecurity.dev/v1alpha1 kind: Rulesfile metadata: name: falco-rules spec: ociArtifact: image: repository: falcosecurity/rules/falco-rules tag: latest registry: name: ghcr.io priority: 50 EOF Check the rulesfile status:\nkubectl get rulesfiles Falco will automatically pick up the rules and start monitoring.\nThe registry.name field defaults to ghcr.io when omitted. The image.tag field defaults to latest.\nRules can also come from inline YAML or Kubernetes ConfigMaps. See the Rulesfile CRD reference for all options.\nAdd Other Plugins Load additional plugins from OCI registries. For example, the k8saudit plugin for Kubernetes audit log monitoring:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: artifact.falcosecurity.dev/v1alpha1 kind: Plugin metadata: name: k8saudit spec: ociArtifact: image: repository: falcosecurity/plugins/plugin/k8saudit tag: latest registry: name: ghcr.io EOF See the Plugin CRD reference for configuration options.\nAdd Ecosystem Components The operator can deploy ecosystem components alongside Falco using the Component CRD.\nFalcosidekick Deploy Falcosidekick to route Falco events to 70+ integrations:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: instance.falcosecurity.dev/v1alpha1 kind: Component metadata: name: sidekick spec: component: type: falcosidekick replicas: 2 EOF Then configure Falco to send events to Falcosidekick:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: artifact.falcosecurity.dev/v1alpha1 kind: Config metadata: name: sidekick-output spec: config: json_output: true http_output: enabled: true url: \u0026#34;http://sidekick:2801\u0026#34; priority: 60 EOF Falcosidekick UI Deploy the web dashboard for event visualization. Requires a Redis instance:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: instance.falcosecurity.dev/v1alpha1 kind: Component metadata: name: sidekick-ui spec: component: type: falcosidekick-ui replicas: 2 EOF Falcosidekick UI requires an external Redis instance. If Redis is not available, pods will stay in Init:0/1 state until Redis becomes reachable. See the Component CRD reference for a complete example with a bundled Redis StatefulSet.\nk8s-metacollector Deploy the centralized Kubernetes metadata collector:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: instance.falcosecurity.dev/v1alpha1 kind: Component metadata: name: metacollector spec: component: type: metacollector replicas: 1 EOF Customize Configuration Override Falco configuration with Config resources:\ncat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: artifact.falcosecurity.dev/v1alpha1 kind: Config metadata: name: custom-config spec: config: engine: kind: modern_ebpf modern_ebpf: buf_size_preset: 4 output_timeout: 2000 priority: 50 EOF Configuration fragments are applied in priority order (0–99) and merged with the base configuration. You can target specific nodes using label selectors. See the Config CRD reference.\nDeployment Modes The operator supports two deployment modes:\nDaemonSet (default) Runs Falco on every node for cluster-wide syscall monitoring using the modern_ebpf driver. This is the standard deployment for runtime security.\nspec: type: DaemonSet Deployment Runs Falco as a regular Deployment instead of a DaemonSet.\nspec: type: Deployment replicas: 2 Uninstall Remove resources in the correct order, artifacts first (so the sidecar can clean up finalizers), then instances, then the operator:\n# 1. Remove artifact resources first kubectl delete rulesfiles --all --all-namespaces kubectl delete plugins --all --all-namespaces kubectl delete configs --all --all-namespaces # 2. Remove instance resources kubectl delete components --all --all-namespaces kubectl delete falco --all --all-namespaces # 3. Remove the operator and CRDs kubectl delete -f https://github.com/falcosecurity/falco-operator/releases/latest/download/install.yaml Deleting Falco instances before artifacts will terminate the Artifact Operator sidecar, leaving artifact finalizers unresolved. Always delete artifact resources (Rulesfile, Plugin, Config) before Falco instances.\nLearn More For complete documentation, including the CRD reference, architecture overview, migration guide, and contributing instructions, visit the Falco Operator repository.\nResource Link Full documentation github.com/falcosecurity/falco-operator/docs CRD reference Falco, Rulesfile, Plugin, Config, Component Architecture Architecture overview Sample manifests config/samples/ ","summary":"","tags":null,"title":"Deploy on Kubernetes with the Operator","url":"https://v0-43--falcosecurity.netlify.app/docs/setup/operator/"},{"category":"docs","content":"First and foremost, if something goes seriously wrong during Falco deployment, it's usually noticeable immediately. On a longer time scale, continuous performance monitoring and quality assurance, driven by the right metrics, ensure Falco functions as expected 24/7.\nAs a security tool, Falco requires checking for a healthy deployment on multiple dimensions:\nResource utilization and system impact: Strive to minimize compute overhead while ensuring the desired monitoring scope is achieved. Disruption/upgrades: Ensure minimal downtime and avoid interruptions to the service, minimizing restarts. Data quality assurance: Verify that Falco outputs contain the desired quality with little to no missing data. End-to-end data pipeline testing: Ensure alerts reach their end destination as quickly as possible. Security monitoring capabilities: Adopting the right Falco rules and resilience to bypasses by attackers. The Falco Project provides guidance on some of these aspects, and there are ongoing long-term efforts, including a partnership with the CNCF TAG Environmental Sustainability, aimed at enhancing Falco's performance and assessing its impact on the system. These efforts are intended to make it easier for adopters to assess the actual impact on their systems, enabling them to make informed decisions about the cost-security monitoring tradeoffs.\nResource Utilization and System Impact The Falco Project provides native support for measuring resource utilization and statistics, including event drop counters, kernel tracepoint invocation counters, timeouts, and internal state handling. More detailed information is given in the Falco Metrics Guide.\nCPU and Memory Utilization On top of the mind for SREs or system admins is how much CPU and memory Falco will utilize on their hosts. They need to assess whether the cost is justified. To maintain excellent relationships with infrastructure teams, setting resource limits for your Falco deployment is crucial. This can be done through systemd or daemonset limits in a Kubernetes environment.\nThis is an essential consideration because running a kernel tool always comes with specific challenges and considerations. For example, it could slow down the kernel or the request rates of applications.\nTop metrics:\nCPU usage: Typically measured as a percentage of one CPU, it can be compared with the number of available CPUs on the host. Falco's hot path is single-threaded, so it should not be able to exceed the capacity of one full CPU. Memory RSS: Resident Set Size is the portion of memory held in RAM by a process. Memory VSZ: Virtual Memory Size is the total memory allocated to a process, including both RAM and swap space. container_memory_working_set_bytes in Kubernetes settings: This is almost equivalent to the cgroups container memory_used metric natively exposed in Falco metrics. Beyond monitoring the tool's utilization, check if your applications perform as before. This evaluation could include overall network, I/O, or general contention metrics.\nRead Falco Metrics next.\nServer Load and Falco Event Drops A common misconception is to think that Falco has constant resource utilization. However, that is not accurate. Falco's utilization is directly dependent on the current workload on the host. The more system calls the applications make, the more work Falco has to handle. You can read our Kernel Testing Framework Proposal for more insights into this topic.\nRead Falco Is Dropping Syscalls Events next.\nTop metrics:\nKernel side and userspace event counts. Kernel side and userspace event drop counts. Kernel tracepoint invocation counts to deduce the overall server load. Userspace timeouts. Falco internal state counters. ","summary":"","tags":null,"title":"Performance","url":"https://v0-43--falcosecurity.netlify.app/docs/troubleshooting/performance/"}]