{"id":1201,"date":"2026-10-11T03:08:29","date_gmt":"2026-10-11T03:08:29","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1201"},"modified":"2026-10-11T03:08:31","modified_gmt":"2026-10-11T03:08:31","slug":"falco-zero-to-intermediate-gold-standard-hands-on-master-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/falco-zero-to-intermediate-gold-standard-hands-on-master-tutorial\/","title":{"rendered":"Falco: Zero to Intermediate &#8211; Gold-Standard Hands-on Master Tutorial"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\"><strong>Last documentation verification:<\/strong>&nbsp;11 October 2026<br><strong>Reference Falco release:<\/strong>&nbsp;0.45.0 (released 21 September 2026)<br><strong>Reference host lab:<\/strong>&nbsp;Ubuntu Server 24.04 LTS, Linux kernel with modern eBPF support<br><strong>Reference companion versions in Falco 0.45.0:<\/strong>&nbsp;falcoctl 0.14.2, falco-rules 5.2.0, Helm chart 9.2.0<br><strong>Audience:<\/strong>&nbsp;Beginners, students, software developers, DevOps engineers, SREs, security engineers<br><strong>Format:<\/strong>&nbsp;180-minute core training, plus optional in-depth reference and stretch exercises<br><strong>Level:<\/strong>&nbsp;Beginner to practical intermediate, with clearly marked production considerations<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Important lab boundaries:<\/strong>&nbsp;Follow the exercise commands only on machines, Docker engines, and Kubernetes clusters you own or are authorized to test. Falco requires privileged Linux kernel access for syscall capture. This guide was checked against published documentation, not executed against a live Falco kernel and Kubernetes cluster in this writing environment. Example outputs are illustrative unless directly described by the cited official quickstarts. Distribution packaging, ruleset versions, Helm values and plugin defaults can evolve. Inspect the installed versions before using the steps in production.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">How to use this book<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The&nbsp;<strong>core path<\/strong>&nbsp;is exactly three hours. In each chapter, do the section labeled&nbsp;<strong>Core<\/strong>&nbsp;first; use the longer explanations, variations and exercises for later study. A new learner can read this in order and keep one Ubuntu virtual machine for Chapters 4-8, 10 and 11. Chapter 9 needs a separate, authorized Kubernetes cluster with Linux nodes.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Ch.<\/th><th class=\"has-text-align-left\" data-align=\"left\">Topic<\/th><th class=\"has-text-align-right\" data-align=\"right\">Core time<\/th><th class=\"has-text-align-left\" data-align=\"left\">Suggested focus<\/th><\/tr><\/thead><tbody><tr><td>1<\/td><td>Introduction to Falco<\/td><td class=\"has-text-align-right\" data-align=\"right\">10 min<\/td><td>Theory 10<\/td><\/tr><tr><td>2<\/td><td>Linux and Security Fundamentals<\/td><td class=\"has-text-align-right\" data-align=\"right\">10 min<\/td><td>Theory 10<\/td><\/tr><tr><td>3<\/td><td>Falco Architecture and Working<\/td><td class=\"has-text-align-right\" data-align=\"right\">15 min<\/td><td>Theory 15<\/td><\/tr><tr><td>4<\/td><td>Falco Installation and Setup<\/td><td class=\"has-text-align-right\" data-align=\"right\">20 min<\/td><td>Theory 5 \/ lab 15<\/td><\/tr><tr><td>5<\/td><td>Falco Runtime Security Detection<\/td><td class=\"has-text-align-right\" data-align=\"right\">20 min<\/td><td>Theory 5 \/ lab 15<\/td><\/tr><tr><td>6<\/td><td>Falco Rules &#8211; Fundamentals to Intermediate<\/td><td class=\"has-text-align-right\" data-align=\"right\">25 min<\/td><td>Theory 5 \/ lab 20<\/td><\/tr><tr><td>7<\/td><td>Writing and Testing Custom Falco Rules<\/td><td class=\"has-text-align-right\" data-align=\"right\">25 min<\/td><td>Lab 25<\/td><\/tr><tr><td>8<\/td><td>Falco Alerts and Integrations<\/td><td class=\"has-text-align-right\" data-align=\"right\">10 min<\/td><td>Lab 10<\/td><\/tr><tr><td>9<\/td><td>Falco with Kubernetes<\/td><td class=\"has-text-align-right\" data-align=\"right\">20 min<\/td><td>Theory 5 \/ lab 15<\/td><\/tr><tr><td>10<\/td><td>Rule Tuning and False Positives<\/td><td class=\"has-text-align-right\" data-align=\"right\">15 min<\/td><td>Lab 15<\/td><\/tr><tr><td>11<\/td><td>Operations, Troubleshooting and Next Steps<\/td><td class=\"has-text-align-right\" data-align=\"right\">10 min<\/td><td>Lab 10<\/td><\/tr><tr><td><strong>Total<\/strong><\/td><td><strong>11 chapters<\/strong><\/td><td class=\"has-text-align-right\" data-align=\"right\"><strong>180 min<\/strong><\/td><td><strong>Theory 55 \/ lab 125<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Realistic timing:<\/strong>&nbsp;The full reference contains more depth than can be read or exercised in 180 minutes. The three-hour plan assumes a prepared Ubuntu VM, downloadable packages, and an existing Kubernetes test cluster. Creating a cluster from scratch, troubleshooting special kernels, or production integration can require substantial additional time.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Required equipment and privileges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Linux x86_64 or ARM64 VM with at least\u00a0<strong>2 vCPUs, 4 GiB RAM and 20 GiB disk<\/strong>\u00a0for the host portion (recommended lab allocation, not an official Falco minimum).<\/li>\n\n\n\n<li>Ubuntu Server 24.04 LTS with\u00a0<code>sudo<\/code>\u00a0privileges and outbound access to the official Falco apt repository. A kernel roughly 5.8 or newer is a useful starting point; the actual requirements are the BPF ring buffer and BTF features, not a fixed version number.<\/li>\n\n\n\n<li>A Docker-capable Linux VM for container exercises; permissions to install a container runtime.<\/li>\n\n\n\n<li>A test Kubernetes cluster with Linux nodes, Helm, kubectl, and permission to deploy privileged node-level security software. Kubernetes 1.29+ is required for the documented Falco Operator path.<\/li>\n\n\n\n<li>A plain-text editor (nano or vim) and ability to copy terminal commands into a Bash shell.<\/li>\n\n\n\n<li>No AWS account, public IP, Slack webhook, or paid service is required for the host labs.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Never run the Falco host monitoring exercise inside an ordinary macOS or Windows shell.<\/strong>&nbsp;Falco&#8217;s syscall sensor observes the Linux kernel. Windows and macOS learners should first create an Ubuntu Linux VM as described in Chapter 4.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 1. Introduction to Falco &#8211; 10 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Explain why runtime threat detection matters, where Falco fits, and when it does not help. At the end you should be able to describe Falco to another engineer in 30 seconds and contrast it with container-image scanning.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is Falco?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Falco is an open-source runtime security detection engine in the cloud-native ecosystem. It observes events from Linux hosts and workloads, evaluates them against security rules, and emits alerts when activity matches a suspicious pattern. Falco commonly runs on a Linux host or as a node-level DaemonSet in Kubernetes. It can also ingest supported external event sources through plugins.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A simple analogy:&nbsp;<strong>an image scanner checks a building blueprint before construction; Falco watches the people entering rooms once the building is in use.<\/strong>&nbsp;Both are helpful, but they answer different questions.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Suppose an application was reviewed, its container image scanned, and its deployment approved. Twenty minutes after it starts, a vulnerability is exploited and the application unexpectedly launches&nbsp;<code>\/bin\/bash<\/code>. Image scanning cannot tell you that it happened at runtime. A Falco rule can watch process execution and alert on a shell appearing in the container.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Why it is needed<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Modern services are ephemeral, frequently deployed, and composed of many third-party dependencies. Security checks made before deployment do not tell you what a process actually did on a running machine. Falco provides the runtime part of a defense-in-depth program:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Development and CI:<\/strong>\u00a0dependency and image scanners find known issues before release.<\/li>\n\n\n\n<li><strong>Deployment:<\/strong>\u00a0admission controls and Kubernetes policy engines guard against unsafe workload configuration.<\/li>\n\n\n\n<li><strong>Runtime:<\/strong>\u00a0Falco observes process, file and network-related events and warns of suspicious behavior.<\/li>\n\n\n\n<li><strong>Response:<\/strong>\u00a0an analyst, SIEM, or separately configured response system investigates and takes action.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Falco vs neighboring tools<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Tool or technique<\/th><th class=\"has-text-align-left\" data-align=\"left\">Main question answered<\/th><th class=\"has-text-align-left\" data-align=\"left\">Example<\/th><th class=\"has-text-align-left\" data-align=\"left\">Falco&#8217;s role<\/th><\/tr><\/thead><tbody><tr><td>SCA \/ dependency scanner<\/td><td>Are vulnerable libraries installed?<\/td><td>A CVE in a package<\/td><td>Not a replacement<\/td><\/tr><tr><td>Image scanner (e.g., Trivy)<\/td><td>Is the built image vulnerable or misconfigured?<\/td><td>Outdated OpenSSL<\/td><td>Complementary<\/td><\/tr><tr><td>Kubernetes admission policy<\/td><td>Should a workload be allowed to start?<\/td><td>Privileged pod rejected<\/td><td>Complementary<\/td><\/tr><tr><td>Linux auditd \/ general logs<\/td><td>What audit\/system records were produced?<\/td><td>User executed a command<\/td><td>Falco adds detection rules and container context<\/td><\/tr><tr><td>SIEM<\/td><td>How do we correlate events across systems?<\/td><td>Alerts from many hosts<\/td><td>Falco is an event\/detection source<\/td><\/tr><tr><td>Falco<\/td><td>What suspicious activity is happening&nbsp;<em>now<\/em>?<\/td><td>Unexpected shell or file access<\/td><td>Primary runtime detector<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Common use cases<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A shell starts inside an application container.<\/li>\n\n\n\n<li>An untrusted process reads\u00a0<code>\/etc\/shadow<\/code>.<\/li>\n\n\n\n<li>A workload modifies a sensitive directory or executable.<\/li>\n\n\n\n<li>Unexpected commands or network connections appear in a host\/container.<\/li>\n\n\n\n<li>Security teams need Kubernetes-oriented runtime observations and audit enrichment.<\/li>\n\n\n\n<li>A cloud audit plugin ingests supported external sources, if separately configured.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What Falco cannot guarantee<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Falco is&nbsp;<strong>primarily detection and alerting<\/strong>, not an automatic prevention control. Without a matching rule, supported event source and healthy collection path, activity may go undetected. It is not a vulnerability scanner, antivirus guarantee, network packet-capture replacement, complete forensics suite, or universal container-escape prevention tool. Rules have false positives and false negatives. Attacks that do not generate monitored events or are deliberately tuned around rule conditions might escape detection. The default plugin configuration also does not mean every cloud or Kubernetes audit source is automatically enabled.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core exercise: identify the tool<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Classify these situations:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>A container image contains an outdated vulnerable package ->\u00a0<strong>image\/SCA scanning<\/strong>.<\/li>\n\n\n\n<li>Someone executes\u00a0<code>bash<\/code>\u00a0inside a running container ->\u00a0<strong>Falco runtime rule<\/strong>.<\/li>\n\n\n\n<li>A developer requests a privileged pod that policy forbids ->\u00a0<strong>admission\/policy control<\/strong>.<\/li>\n\n\n\n<li>Events from dozens of clusters need centralized correlation ->\u00a0<strong>SIEM\/observability<\/strong>, with Falco as an input.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Knowledge check (answers included)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0Does Falco replace image scanning?\u00a0<strong>A:<\/strong>\u00a0No; Falco detects runtime behavior, scanners inspect artifacts and dependencies.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Does Falco block a suspicious action by default?\u00a0<strong>A:<\/strong>\u00a0No; its primary product behavior is to alert.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Why install on every Kubernetes node?\u00a0<strong>A:<\/strong>\u00a0Workloads can execute on any node, so kernel events must be collected where processes run.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>You are ready for Chapter 2 when:<\/strong>&nbsp;you can explain the difference between prevention, scanning, detection and response.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/\">https:\/\/falco.org\/docs\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/\">https:\/\/falco.org\/docs\/concepts\/<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 2. Linux and Security Fundamentals &#8211; 10 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Understand the Linux events and process metadata that Falco rules evaluate. You do not need prior kernel programming knowledge.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Processes, IDs, users and permissions<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A&nbsp;<strong>process<\/strong>&nbsp;is a running program. The kernel assigns a&nbsp;<strong>PID<\/strong>&nbsp;(process ID). A process usually has a parent process (PPID), an executable, command-line arguments, and a security identity (UID\/GID). Linux file permissions and capabilities control what an identity may do. A container adds isolation mechanisms but still uses its host&#8217;s Linux kernel.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Run in your Ubuntu terminal (no sudo needed):<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Show your effective user and numeric IDs<\/em>\nid\n\n<em># Show a sample of running processes and their parent IDs<\/em>\nps -eo pid,ppid,user,comm,args | head -n 12\n\n<em># Show the Linux kernel release<\/em>\nuname -r\n\n<em># Show permissions on important configuration files<\/em>\nls -l \/etc\/passwd \/etc\/shadow\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Verify:<\/strong>&nbsp;<code>id<\/code>&nbsp;shows UID\/GID,&nbsp;<code>ps<\/code>&nbsp;shows PID\/PPID, and&nbsp;<code>\/etc\/shadow<\/code>&nbsp;is normally not readable by an ordinary user. The exact output depends on your Linux image.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">System calls: the interface between programs and the kernel<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A user-space process cannot directly read arbitrary protected files or create arbitrary network sockets. It asks the kernel through a&nbsp;<strong>system call (syscall)<\/strong>. Falco&#8217;s Linux event source captures selected syscall activity and other supported events, then enriches it with useful context.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Event family<\/th><th class=\"has-text-align-left\" data-align=\"left\">Meaning<\/th><th class=\"has-text-align-left\" data-align=\"left\">Security question<\/th><\/tr><\/thead><tbody><tr><td><code>execve<\/code>&nbsp;\/&nbsp;<code>execveat<\/code><\/td><td>Execute a program<\/td><td>Did a shell or unexpected executable start?<\/td><\/tr><tr><td><code>open<\/code>&nbsp;\/&nbsp;<code>openat<\/code>&nbsp;\/&nbsp;<code>openat2<\/code><\/td><td>Open a file<\/td><td>Did an unexpected process access a sensitive file?<\/td><\/tr><tr><td><code>connect<\/code><\/td><td>Initiate a socket connection<\/td><td>Did a process establish an unusual connection?<\/td><\/tr><tr><td><code>chmod<\/code>&nbsp;\/ permission changes<\/td><td>Change file permissions<\/td><td>Was a protected file modified?<\/td><\/tr><tr><td>Process-related events<\/td><td>Lifecycle and process metadata<\/td><td>Who launched this program and under which identity?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">An application call such as&nbsp;<code>cat \/etc\/passwd<\/code>&nbsp;may involve a new process and file-opening system calls.&nbsp;<strong>An attempted syscall and a successful syscall are different events\/results.<\/strong>&nbsp;Good rules examine event types and, when applicable, the result (<code>evt.failed<\/code>&nbsp;or&nbsp;<code>evt.rawres<\/code>).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Container isolation concepts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A\u00a0<strong>namespace<\/strong>\u00a0gives processes a restricted view of PIDs, mounts, networks, and other resources.<\/li>\n\n\n\n<li>A\u00a0<strong>cgroup<\/strong>\u00a0manages and identifies groups of processes and constrains resource usage.<\/li>\n\n\n\n<li>A\u00a0<strong>container runtime<\/strong>\u00a0creates and manages container processes.<\/li>\n\n\n\n<li>A\u00a0<strong>Kubernetes Pod<\/strong>\u00a0groups containers and adds orchestration metadata.<\/li>\n\n\n\n<li>Containers generally share the host kernel; this is why Falco observes their runtime activity at the node.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">A Falco rule can use&nbsp;<code>proc.name<\/code>&nbsp;to select the executing process,&nbsp;<code>user.name<\/code>&nbsp;to report its identity,&nbsp;<code>fd.name<\/code>&nbsp;to name a file or socket, and&nbsp;<code>container.id<\/code>&nbsp;to distinguish containerized activity from host activity.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core exercise: reason about events<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Execute:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Creates a new process and opens \/etc\/passwd for reading<\/em>\ncat \/etc\/passwd &gt; \/dev\/null\n\n<em># Opens an ordinary lab file for writing<\/em>\nprintf 'hello Falco\\n' &gt; \/tmp\/falco-intro.txt\n\n<em># View the file you just created<\/em>\ncat \/tmp\/falco-intro.txt\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Predict the events that could be relevant to runtime rules: an executable launch (when a new program is started), a file opened for reading, and a file opened for writing. Exact captured event types can vary by process implementation and the Falco driver&#8217;s instrumentation.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Cleanup:<\/strong>&nbsp;<code>rm -f \/tmp\/falco-intro.txt<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Knowledge check<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0Is a PID a process name?\u00a0<strong>A:<\/strong>\u00a0No; it is a numeric process identifier.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Is\u00a0<code>execve<\/code>\u00a0itself malicious?\u00a0<strong>A:<\/strong>\u00a0No; it is an ordinary syscall. Security comes from the circumstances, process and rule.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Are containers separate kernels?\u00a0<strong>A:<\/strong>\u00a0Normally not; standard Linux containers share the host kernel.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>You are ready for Chapter 3 when:<\/strong>&nbsp;you can explain why a file read or process spawn has meaningful syscall evidence.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/event-sources\/kernel\/\">https:\/\/falco.org\/docs\/concepts\/event-sources\/kernel\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/rules\/supported-fields\/\">https:\/\/falco.org\/docs\/rules\/supported-fields\/<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 3. Falco Architecture and Working &#8211; 15 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Trace a kernel event from an application to a Falco rule and an output destination, and know what modern eBPF, the kernel module, plugins, libscap and libsinsp do.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture diagram<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>flowchart TD\n    A&#91;Linux apps and container processes] --&gt; B&#91;Linux kernel syscalls and tracepoints]\n    B --&gt; C&#91;Modern eBPF probe or kernel module]\n    C --&gt; D&#91;libscap event collection]\n    D --&gt; E&#91;libsinsp inspection and enrichment]\n    F&#91;External events through source plugins] --&gt; E\n    G&#91;Container metadata plugin] --&gt; E\n    E --&gt; H&#91;Falco rules engine]\n    I&#91;Rules, macros and lists] --&gt; H\n    H --&gt; J{Rule matched?}\n    J --&gt;|Yes| K&#91;Alert format and priority]\n    J --&gt;|No| L&#91;Continue monitoring]\n    K --&gt; M&#91;stdout, file, syslog or HTTP]\n    M --&gt; N&#91;Falcosidekick, SIEM or alert workflows]\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Reading the diagram:<\/strong>&nbsp;Linux processes make syscalls; a kernel instrumentation driver captures relevant activity; Falco libraries translate and enrich it; rules evaluate events; alerts go to configured outputs. Plugin-sourced events enter through the event-source plugin mechanism rather than through Linux syscall capture. Enrichment plugin fields require the relevant plugin to be loaded\/configured.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Modern eBPF vs kernel module<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>eBPF (extended Berkeley Packet Filter)<\/strong>&nbsp;enables bounded, verified programs to run in the Linux kernel to observe events. Falco&#8217;s&nbsp;<strong>modern eBPF probe<\/strong>&nbsp;is embedded in the Falco userspace binary. It uses BPF Type Format (BTF) information and a BPF ring buffer; the driver documentation indicates that kernels &gt;=5.8 are&nbsp;<em>usually<\/em>&nbsp;sufficient, but capability detection matters more than a simple version check. Since Falco 0.38.0, modern eBPF is the default driver; it remains the standard in 0.45.0.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A&nbsp;<strong>kernel module<\/strong>&nbsp;is a separately installed kernel component. It can support some older\/incompatible kernel environments but requires suitable privileges, a matching driver build and careful version compatibility. A kernel module is not inherently the safer option for a beginner.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Do not use old tutorials that recommend legacy eBPF, gVisor engine, or Falco gRPC output for modern releases.<\/strong>&nbsp;They were removed in Falco 0.44.0. The modern eBPF sensor is different from the removed&nbsp;<em>legacy eBPF<\/em>&nbsp;implementation.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Topic<\/th><th class=\"has-text-align-left\" data-align=\"left\">Modern eBPF<\/th><th class=\"has-text-align-left\" data-align=\"left\">Kernel module<\/th><\/tr><\/thead><tbody><tr><td>Beginner recommendation<\/td><td>Default if supported<\/td><td>Fallback if necessary<\/td><\/tr><tr><td>Kernel-side artifact<\/td><td>Embedded CO-RE probe loaded by Falco<\/td><td>Separate&nbsp;<code>.ko<\/code>&nbsp;module<\/td><\/tr><tr><td>Requirements<\/td><td>BPF ring buffer and BTF features<\/td><td>Compatible module \/ kernel build<\/td><\/tr><tr><td>Operational issue to investigate<\/td><td>Privileges, BTF, feature support, lockdown<\/td><td>Build\/signing, Secure Boot, module mismatch<\/td><\/tr><tr><td>Monitoring scope<\/td><td>Linux kernel events<\/td><td>Linux kernel events<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">libscap and libsinsp<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>libscap<\/code>&nbsp;handles low-level event capture and driver interaction.&nbsp;<code>libsinsp<\/code>&nbsp;builds inspectable event and process context used by Falco. The container plugin can enrich events with names\/images by communicating with supported container runtimes. On Kubernetes, additional metadata enrichment can associate container IDs with pods and namespaces.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What plugins do<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Two important distinctions:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Event-source plugins<\/strong>\u00a0supply events such as supported cloud\/audit streams rather than syscall events. They must be configured with the appropriate inputs and permissions.<\/li>\n\n\n\n<li><strong>Field-extraction\/enrichment plugins<\/strong>\u00a0add context to events, such as container or Kubernetes metadata. They do not automatically mean that external audit logs are collected.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">For example, a Kubernetes process-execution alert is a&nbsp;<strong>syscall event about a pod&#8217;s process<\/strong>. A Kubernetes API audit event, if configured through a relevant source plugin, is a&nbsp;<strong>control-plane event about an API request<\/strong>. These are not interchangeable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Working example: concept-to-alert walk-through<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>A process in an authorized test container starts\u00a0<code>bash<\/code>.<\/li>\n\n\n\n<li>The kernel observes an\u00a0<code>execve<\/code>\/<code>execveat<\/code>\u00a0execution event.<\/li>\n\n\n\n<li>Falco&#8217;s driver delivers a selected event to the inspection pipeline.<\/li>\n\n\n\n<li>The rule engine tests\u00a0<code>evt.type<\/code>,\u00a0<code>proc.name<\/code>, and\u00a0<code>container.id<\/code>.<\/li>\n\n\n\n<li>If the condition matches, an alert includes the rule name, priority, command, user, and (if available) container metadata.<\/li>\n\n\n\n<li>A configured output sends that alert to journald\/stdout or an HTTP receiver such as Falcosidekick.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Core exercise: match architecture to commands<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">When Falco is installed later, run:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Inspect the installed binary's Falco, library and driver requirements<\/em>\nsudo falco --version\n\n<em># List supported field names for syscall-based rules<\/em>\nsudo falco --list=syscall -N | head -n 30\n\n<em># List the available event types (read only)<\/em>\nsudo falco --list-events | head -n 30\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Do not be surprised if some fields show&nbsp;<code>container<\/code>&nbsp;or plugin-specific metadata on one deployment but not another; what is available depends on the loaded plugins and configuration.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Knowledge check<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0Which layer translates kernel driver events for user space?\u00a0<strong>A:<\/strong>\u00a0<code>libscap<\/code>.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Is a Kubernetes audit event the same as a syscall event?\u00a0<strong>A:<\/strong>\u00a0No; they have distinct sources and meanings.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Is modern eBPF the same as the removed legacy eBPF probe?\u00a0<strong>A:<\/strong>\u00a0No.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Can an eBPF rule be evaluated before the Falco engine sees it?\u00a0<strong>A:<\/strong>\u00a0Event collection and user-space rule evaluation are separate stages; the kernel probe is not itself a replacement for the Falco rules engine.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>You are ready for Chapter 4 when:<\/strong>&nbsp;you can explain the flow&nbsp;<code>syscall -&gt; driver -&gt; Falco inspection -&gt; rule -&gt; alert<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/event-sources\/kernel\/architecture\/\">https:\/\/falco.org\/docs\/concepts\/event-sources\/kernel\/architecture\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/event-sources\/kernel\/\">https:\/\/falco.org\/docs\/concepts\/event-sources\/kernel\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/plugins\/\">https:\/\/falco.org\/docs\/concepts\/plugins\/<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 4. Falco Installation and Setup &#8211; 20 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Build one functional Falco Linux host, confirm event capture, find its configuration, and safely prepare a custom-rules directory. You will learn installation and service management rather than merely copying commands.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Quick installation and configuration (Windows, macOS and Ubuntu)<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A recurring question is, &#8220;Can I just run Falco on my MacBook or Windows laptop?&#8221; Not for Linux syscall inspection of the native macOS or Windows kernel.&nbsp;<strong>Use a real Linux virtual machine; execute all Falco commands inside it.<\/strong>&nbsp;A macOS\/Windows terminal is used only to create and enter the VM. Docker Desktop on Windows or macOS is also not the recommended shortcut for the Kubernetes Falco sensor lab; use a cluster with accessible Linux nodes instead.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Path A: Windows 10\/11 with Ubuntu using Canonical Multipass<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Prerequisites:<\/strong>&nbsp;administrator access; a working hardware virtualization backend (Hyper-V or another provider supported by the installed Multipass version); sufficient available memory and disk space. On corporate-managed computers, check virtualization\/VM policy first.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Download the current Multipass Windows installer from\u00a0<a href=\"https:\/\/canonical.com\/multipass\/install\">https:\/\/canonical.com\/multipass\/install<\/a>\u00a0. Run it as administrator and complete the official installer. An exact unattended installer command is intentionally not supplied because the installer version and URL are not fixed; do not paste an unverified external URL into an elevated PowerShell session.<\/li>\n\n\n\n<li>Open a\u00a0<strong>new Windows PowerShell<\/strong>\u00a0session (ordinary user after installation) and run:<\/li>\n<\/ol>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Confirm Windows can locate the installed command<\/em>\nmultipass version\n\n<em># Create an Ubuntu 24.04 VM; allocation assumes enough free host resources<\/em>\nmultipass launch 24.04 --name falco-lab --cpus 2 --memory 4G --disk 20G\n\n<em># Verify the instance is Running<\/em>\nmultipass list\n\n<em># Enter the Ubuntu shell. All further apt\/Falco commands are run inside Ubuntu.<\/em>\nmultipass shell falco-lab\n<\/code><\/pre>\n\n\n\n<ol start=\"3\" class=\"wp-block-list\">\n<li><strong>Expected:<\/strong>\u00a0the prompt changes to a Linux shell. In Ubuntu, run\u00a0<code>uname -s<\/code>; it should say\u00a0<code>Linux<\/code>. Continue with the Ubuntu installation below.<\/li>\n\n\n\n<li><strong>If launch fails:<\/strong>\u00a0verify virtualization is enabled and that the Multipass service and configured virtualization backend are working; inspect\u00a0<code>multipass info falco-lab<\/code>. Do not assume WSL2&#8217;s kernel offers the required modern eBPF environment; a full VM is more predictable for this exercise.<\/li>\n\n\n\n<li><strong>Cleanup later (PowerShell, not Ubuntu):<\/strong>\u00a0<code>multipass delete falco-lab --purge<\/code>\u00a0<strong>permanently removes the VM and its files<\/strong>. Back up custom rules first.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Path B: macOS (Intel or Apple Silicon) with Lima<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Prerequisites:<\/strong>&nbsp;supported macOS, Homebrew already installed from&nbsp;<a href=\"https:\/\/brew.sh\/\">https:\/\/brew.sh\/<\/a>&nbsp;, virtualization permitted on your Mac. Lima creates an Ubuntu Linux VM; Falco monitors&nbsp;<em>that Ubuntu VM<\/em>, not all processes running directly on macOS.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Run in macOS Terminal:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Install Lima using Homebrew<\/em>\nbrew install lima\n\n<em># Confirm Lima CLI was installed<\/em>\nlimactl --version\n\n<em># Create Ubuntu VM using the current Ubuntu LTS Lima template<\/em>\nlimactl start --name=falco-lab template:\/\/ubuntu-lts\n\n<em># Check VM state<\/em>\nlimactl list\n\n<em># Enter the Ubuntu VM<\/em>\nlimactl shell falco-lab\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;you enter a Linux shell. Verify with&nbsp;<code>uname -s<\/code>,&nbsp;<code>uname -m<\/code>, and&nbsp;<code>cat \/etc\/os-release<\/code>. The&nbsp;<code>ubuntu-lts<\/code>&nbsp;template selects the configured current LTS image; for a strict 24.04 exercise, verify the image release before continuing or use an explicit 24.04 Lima template appropriate for your Lima installation.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>If VM startup fails:<\/strong>&nbsp;check virtualization permission, free disk\/RAM and&nbsp;<code>limactl list<\/code>; check the Lima documentation for platform-specific VM drivers.&nbsp;<code>brew install lima<\/code>&nbsp;installs the VM manager only, not Falco itself.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Cleanup later (macOS Terminal):<\/strong>&nbsp;<code>limactl stop falco-lab &amp;&amp; limactl delete falco-lab<\/code>&nbsp;removes the test VM once you confirm no needed files remain.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Path C: Ubuntu Linux 24.04 (native host or VM)<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Prerequisites:<\/strong>&nbsp;a disposable or explicitly authorized Ubuntu environment with&nbsp;<code>sudo<\/code>, outbound HTTPS, and a Linux kernel supporting modern eBPF features.&nbsp;<strong>Do not install this lab onto a production machine.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Run inside an Ubuntu Bash shell (also applies after entering Windows\/macOS Ubuntu VMs):<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># 1. Identify the machine and verify it is Linux<\/em>\nuname -s\nuname -r\ncat \/etc\/os-release\nid\n\n<em># 2. Prepare standard apt\/repository tools<\/em>\nsudo apt-get update\nsudo apt-get install -y curl ca-certificates gnupg dialog\n\n<em># 3. Install Falco's official APT signing key (keyring, not apt-key)<\/em>\nsudo install -d -m 0755 \/usr\/share\/keyrings\ncurl -fsSL https:\/\/falco.org\/repo\/falcosecurity-packages.asc | \\\n  sudo gpg --dearmor -o \/usr\/share\/keyrings\/falco-archive-keyring.gpg\n\n<em># 4. Add Falco's signed official package repository<\/em>\nprintf '%s\\n' \\\n  'deb &#91;signed-by=\/usr\/share\/keyrings\/falco-archive-keyring.gpg] https:\/\/download.falco.org\/packages\/deb stable main' | \\\n  sudo tee \/etc\/apt\/sources.list.d\/falcosecurity.list &gt; \/dev\/null\n\n<em># 5. Refresh package indexes and inspect the repository candidate<\/em>\nsudo apt-get update\napt-cache policy falco\n\n<em># 6. Install Falco and accompanying package components<\/em>\nsudo apt-get install -y falco\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Interactive installer:<\/strong>&nbsp;select&nbsp;<strong>Modern eBPF<\/strong>&nbsp;when prompted for a driver and accept official automatic rules updates for the training VM if offered. Package prompts differ by version and by whether apt is interactive. Falco 0.45.0 is the verified reference release;&nbsp;<code>apt-cache policy falco<\/code>&nbsp;and&nbsp;<code>falco --version<\/code>&nbsp;determine the actual package you received. If the repository has published a newer version by the time you run this, consult its release notes before changing example configurations.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Why these commands matter:<\/strong>&nbsp;We install dependencies, import the repository signing key into its own keyring, register a signed package source, refresh apt indexes, then install Falco with systemd integration.&nbsp;<code>sudo<\/code>&nbsp;is needed for system-wide package operations and runtime inspection permissions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Start, enable and verify the service<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Report the installed Falco version and companion API information<\/em>\nsudo falco --version\n\n<em># Start the modern eBPF Falco unit and enable it at boot<\/em>\nsudo systemctl enable --now falco-modern-bpf.service\n\n<em># Verify it is active<\/em>\nsudo systemctl is-active falco-modern-bpf.service\nsudo systemctl status falco-modern-bpf.service --no-pager\n\n<em># Show recent daemon logs and verify the syscall source opened<\/em>\nsudo journalctl -u falco-modern-bpf.service -n 60 --no-pager\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;<code>is-active<\/code>&nbsp;says&nbsp;<code>active<\/code>, and logs report rules loading and the syscall source using modern eBPF. If you receive&nbsp;<code>Unit ... could not be found<\/code>, check the installed unit names with&nbsp;<code>systemctl list-unit-files | grep falco<\/code>, and confirm which driver\/service you selected during package setup. Do not start several Falco instances on a production node just to find a working one.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Inspect files and make a backup<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># List the installed configuration\/rule paths<\/em>\nsudo ls -la \/etc\/falco\nsudo ls -la \/etc\/falco\/rules.d\n\n<em># Preserve original configuration before experimenting<\/em>\nsudo cp -a \/etc\/falco\/falco.yaml \/etc\/falco\/falco.yaml.lab-backup\n\n<em># Search the actual configuration for selected settings<\/em>\nsudo grep -nE '^(engine:|rules_files:|json_output:|stdout_output:|syslog_output:|http_output:)' \/etc\/falco\/falco.yaml\n\n<em># List available runtime fields and defined rule names<\/em>\nsudo falco --list=syscall -N | head -n 25\nsudo falco -L | head -n 45\n\n<em># Parse configuration\/rules without consuming runtime events<\/em>\nsudo falco --dry-run -c \/etc\/falco\/falco.yaml\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Important paths (host packages):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/falco\/\n|-- falco.yaml                 # Main daemon settings\n|-- falco_rules.yaml           # Distribution\/default rules (do not hand-edit)\n|-- falco_rules.local.yaml     # Local override file (if shipped)\n`-- rules.d\/                   # Recommended home for new rules\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Modern distributions can also install rules\/plug-ins as managed artifacts via&nbsp;<code>falcoctl<\/code>. Check&nbsp;<code>rules_files:<\/code>&nbsp;on your host rather than assuming every installation has the same list. The typical default loads the official file followed by local rules and the&nbsp;<code>rules.d<\/code>&nbsp;directory; the order matters when overriding\/tuning.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Configuration essentials<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Setting\/feature<\/th><th class=\"has-text-align-left\" data-align=\"left\">Purpose<\/th><th class=\"has-text-align-left\" data-align=\"left\">Learning guidance<\/th><\/tr><\/thead><tbody><tr><td><code>engine.kind: modern_ebpf<\/code><\/td><td>Choose the modern eBPF capture engine<\/td><td>Default\/current recommendation if supported<\/td><\/tr><tr><td><code>rules_files<\/code><\/td><td>Ordered rule file paths<\/td><td>Put custom rules in&nbsp;<code>rules.d<\/code>&nbsp;when included<\/td><\/tr><tr><td><code>json_output<\/code><\/td><td>Structured one-JSON-object-per-alert output<\/td><td>Useful for machines\/SIEM<\/td><\/tr><tr><td><code>stdout_output.enabled<\/code><\/td><td>Print alerts to stdout<\/td><td>Convenient in containers<\/td><\/tr><tr><td><code>syslog_output.enabled<\/code><\/td><td>Forward to syslog<\/td><td>Convenient on traditional hosts<\/td><\/tr><tr><td><code>http_output.enabled<\/code>&nbsp;\/&nbsp;<code>url<\/code><\/td><td>Send alerts to HTTP receiver<\/td><td>Falcosidekick or other receiver<\/td><\/tr><tr><td><code>metrics.enabled<\/code><\/td><td>Emit Falco operational metrics<\/td><td>Turn on for production observation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Do not blindly overwrite the entire production&nbsp;<code>falco.yaml<\/code>.<\/strong>&nbsp;Make small, reviewed, reversible changes and preserve defaults required by your installed version.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Installation diagnostics<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Symptom<\/th><th class=\"has-text-align-left\" data-align=\"left\">First diagnostic<\/th><th class=\"has-text-align-left\" data-align=\"left\">Likely corrective action<\/th><th class=\"has-text-align-left\" data-align=\"left\">Success criterion<\/th><\/tr><\/thead><tbody><tr><td><code>apt<\/code>&nbsp;cannot locate package<\/td><td><code>apt-cache policy falco<\/code>; inspect repo file<\/td><td>Check apt update, official URL, signing key, proxy\/DNS<\/td><td>Candidate version listed<\/td><\/tr><tr><td><code>NO_PUBKEY<\/code>&nbsp;or signature error<\/td><td><code>sudo apt-get update<\/code>&nbsp;output<\/td><td>Reimport official key; verify URL and keyring file permissions<\/td><td>Apt index refresh succeeds<\/td><\/tr><tr><td>Falco service not found<\/td><td>`systemctl list-unit-files<\/td><td>grep falco`<\/td><td>Confirm package installed and selected driver unit<\/td><\/tr><tr><td>Falco fails opening eBPF probe<\/td><td><code>sudo journalctl -u falco-modern-bpf.service -n 100<\/code><\/td><td>Check kernel BTF\/ring-buffer support, capabilities, kernel lockdown, VM type<\/td><td>Logs show syscall source opened<\/td><\/tr><tr><td>Permission denied<\/td><td><code>id<\/code>; service logs<\/td><td>Run under documented privileges or supported service unit<\/td><td>Falco runs without permission error<\/td><\/tr><tr><td>VM has no&nbsp;<code>systemd<\/code><\/td><td><code>ps -p 1 -o comm=<\/code><\/td><td>Use full Ubuntu VM\/native host<\/td><td>PID 1 is systemd<\/td><\/tr><tr><td>No rule alerts<\/td><td>Chapter 5 checklist<\/td><td>Verify the service, rules loaded, alert output, and event trigger<\/td><td>Controlled test generates alert<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Knowledge check<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0Why does a Mac or Windows learner need an Ubuntu VM?\u00a0<strong>A:<\/strong>\u00a0Falco&#8217;s syscall driver observes a Linux kernel, not the native macOS\/Windows kernel.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0What is the simplest post-install service check?\u00a0<strong>A:<\/strong>\u00a0<code>sudo systemctl is-active falco-modern-bpf.service<\/code>, followed by the service journal.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Where should environment-specific rule files usually live?\u00a0<strong>A:<\/strong>\u00a0Under\u00a0<code>\/etc\/falco\/rules.d<\/code>\u00a0when that directory is included in\u00a0<code>rules_files<\/code>, rather than modifying the vendor-managed rules file.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0What proves syntax\/configuration correctness before runtime monitoring?\u00a0<strong>A:<\/strong>\u00a0<code>falco --dry-run<\/code>, supplemented by\u00a0<code>falco -V<\/code>\u00a0to validate specific rule files.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Completion checkpoint:<\/strong>&nbsp;<code>sudo falco --version<\/code>,&nbsp;<code>systemctl is-active<\/code>&nbsp;and&nbsp;<code>journalctl<\/code>&nbsp;all work. You know where configuration and custom rules belong.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/getting-started\/falco-linux-quickstart\/\">https:\/\/falco.org\/docs\/getting-started\/falco-linux-quickstart\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/installation\/\">https:\/\/falco.org\/docs\/installation\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/reference\/daemon\/config-options\/\">https:\/\/falco.org\/docs\/reference\/daemon\/config-options\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/canonical.com\/multipass\/install\">https:\/\/canonical.com\/multipass\/install<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 5. Falco Runtime Security Detection &#8211; 20 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Trigger a real, controlled runtime detection on a Linux VM and read the alert context. Extend that detection to a container, then examine file modification behavior.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What does a detection actually mean?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A runtime alert is evidence that&nbsp;<strong>an observed event matched a rule<\/strong>. It is not automatically proof of compromise. The analyst must determine who initiated the activity, whether it was expected, what the process accessed, and whether its behavior deserves a response. Rules should be evaluated for the workload&#8217;s normal baseline.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab 5A: read a sensitive file without leaking it<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Prerequisite:<\/strong>&nbsp;the Chapter 4 Ubuntu host with Falco active.&nbsp;<strong>Terminal A<\/strong>&nbsp;watches Falco logs;&nbsp;<strong>Terminal B<\/strong>&nbsp;generates one safe test event.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Terminal A (Ubuntu):<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Stream the journal for Falco's modern eBPF service<\/em>\nsudo journalctl -fu falco-modern-bpf.service\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Terminal B (same Ubuntu VM):<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Access sensitive system metadata as root, discarding every output byte<\/em>\nsudo cat \/etc\/shadow &gt; \/dev\/null\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;on the documented default ruleset, an alert similar to&nbsp;<code>Sensitive file opened for reading by non-trusted program<\/code>&nbsp;appears, often with priority&nbsp;<code>Warning<\/code>. It may include file&nbsp;<code>\/etc\/shadow<\/code>, process&nbsp;<code>cat<\/code>, user&nbsp;<code>root<\/code>, parent process&nbsp;<code>sudo<\/code>, and&nbsp;<code>container_id=host<\/code>. Exact wording and activation depends on your installed ruleset and configured outputs.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Why it works:<\/strong>&nbsp;the rule assesses file access by the process, not whether the contents were printed. Redirecting to&nbsp;<code>\/dev\/null<\/code>&nbsp;prevents displaying or recording password hashes in training notes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Verification if the streaming terminal shows no alert:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Did Falco start and load rules?<\/em>\nsudo systemctl is-active falco-modern-bpf.service\nsudo journalctl -u falco-modern-bpf.service -n 100 --no-pager\n\n<em># Are rules loaded and is the relevant behavior covered?<\/em>\nsudo falco -L | grep -i -E 'sensitive|shadow|shell' | head -n 20\n\n<em># Search recent journal entries; output path may differ by configuration<\/em>\nsudo journalctl _COMM=falco --since '10 minutes ago' --no-pager | grep -i -E 'Sensitive|shadow'\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">If the default rule is not shipped\/enabled in your installed ruleset, do not assume that Falco itself failed. Chapter 7 includes a deterministic custom rule exercise.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab 5B: detect shell execution in a container<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Prerequisite:<\/strong>&nbsp;Docker Engine installed&nbsp;<em>inside the Ubuntu lab VM<\/em>, with the Falco service on that same Linux host. Do not execute Docker containers on macOS\/Windows Docker Desktop while monitoring a separate VM; the events will be on a different Linux kernel.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Install a lab Docker Engine if not already present (Ubuntu):<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo apt-get update\nsudo apt-get install -y docker.io\nsudo systemctl enable --now docker\nsudo docker version\nsudo docker info --format '{{.ServerVersion}}'\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">This uses Ubuntu&#8217;s distribution-packaged&nbsp;<code>docker.io<\/code>&nbsp;for convenience in a&nbsp;<strong>disposable lab<\/strong>. For a managed production environment, evaluate the supported vendor runtime\/packages, update policy and Falco container-plugin integration separately.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Terminal A:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo journalctl -fu falco-modern-bpf.service\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Terminal B:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Download a small published image if not already present<\/em>\nsudo docker pull ubuntu:24.04\n\n<em># Run a short shell inside a new named Linux container<\/em>\nsudo docker run --rm --name falco-training ubuntu:24.04 \\\n  bash -c 'id; echo falco-container-lab; sleep 2'\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;if a shell-in-container default rule is enabled and matches the exact shell behavior, you should see an execution-related alert. Some default rules require an interactive terminal; in that case try a terminal-attached session in a real terminal:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo docker run --rm -it --name falco-interactive ubuntu:24.04 bash\n<em># Inside the container type: id<\/em>\n<em># Then type: exit<\/em>\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Important:<\/strong>&nbsp;A container shell is not automatically a security incident. It can be an authorized diagnostic action. You will create an explicit custom detection for this action in Chapter 7, without relying on changing names\/default behavior of distribution rules.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab 5C: understand sensitive file modifications safely<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">We want to detect&nbsp;<strong>writes<\/strong>, but we should not change&nbsp;<code>\/etc\/shadow<\/code>&nbsp;or alter system configuration. Chapter 7 creates a rule that treats&nbsp;<code>\/tmp\/falco-lab-protected.txt<\/code>&nbsp;as a mock sensitive path. For now, use:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>printf 'initial contents\\n' &gt; \/tmp\/falco-lab-protected.txt\nprintf 'authorized lab modification\\n' &gt;&gt; \/tmp\/falco-lab-protected.txt\ncat \/tmp\/falco-lab-protected.txt\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">You should&nbsp;<strong>not<\/strong>&nbsp;expect a default Falco rule to alert on an ordinary&nbsp;<code>\/tmp<\/code>&nbsp;file. This is intentional: writing benign files is expected Linux behavior. A custom rule gives meaning to your controlled path and proves the policy can be tailored.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to read an alert<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A representative, illustrative text alert might look like:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>12:34:56.000000000: Warning Sensitive file opened for reading by non-trusted program\n(file=\/etc\/shadow user=root process=cat parent=sudo container_id=host)\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Analyze these fields in order:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Time:<\/strong>\u00a0when the matching event occurred (verify timezone and collection latency).<\/li>\n\n\n\n<li><strong>Severity:<\/strong>\u00a0informational classification configured on the rule; not an automated incident verdict.<\/li>\n\n\n\n<li><strong>Rule name:<\/strong>\u00a0which rule matched; use this to find its source YAML.<\/li>\n\n\n\n<li><strong>Process \/ command:<\/strong>\u00a0the process and its arguments; beware that command lines may contain secrets.<\/li>\n\n\n\n<li><strong>User \/ parent:<\/strong>\u00a0identity and process ancestry, useful for differentiating a scheduled job from an injected shell.<\/li>\n\n\n\n<li><strong>File \/ connection target:<\/strong>\u00a0the resource accessed.<\/li>\n\n\n\n<li><strong>Container \/ Kubernetes context:<\/strong>\u00a0if available, which workload triggered it.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Common mistakes and fixes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Nothing appears:<\/strong>\u00a0check that the test runs on the\u00a0<strong>same Linux node<\/strong>\u00a0as Falco; confirm the correct service and alert output are in use.<\/li>\n\n\n\n<li><strong>A container ID appears as\u00a0<code>host<\/code>:<\/strong>\u00a0the event was host-side, or container context was not captured as expected; check namespace\/cgroup\/container metadata and plugin setup.<\/li>\n\n\n\n<li><strong>The rule does not fire for\u00a0<code>bash -c<\/code>:<\/strong>\u00a0some default rules are terminal-specific; use an interactive shell or Chapter 7&#8217;s explicit custom rule.<\/li>\n\n\n\n<li><strong>Too many alerts:<\/strong>\u00a0do not globally disable detections; first identify the offending rule and what normal activity produces the noise.<\/li>\n\n\n\n<li><strong>Unexpected sensitive content in logs:<\/strong>\u00a0stop logging unnecessary command arguments and redact in your forwarding\/retention layer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Knowledge check<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0Why direct\u00a0<code>\/etc\/shadow<\/code>\u00a0to\u00a0<code>\/dev\/null<\/code>?\u00a0<strong>A:<\/strong>\u00a0To trigger a read without displaying the content.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Does a rule trigger simply because a path looks sensitive?\u00a0<strong>A:<\/strong>\u00a0No; it needs an event and a matching loaded rule.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Is a shell inside a container always malicious?\u00a0<strong>A:<\/strong>\u00a0No; it can be legitimate, though often worth investigating.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Completion checkpoint:<\/strong>&nbsp;You can trigger and find a Falco runtime alert, identify its rule\/priority\/process and explain why it fired.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/getting-started\/falco-linux-quickstart\/\">https:\/\/falco.org\/docs\/getting-started\/falco-linux-quickstart\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/getting-started\/falco-docker-quickstart\/\">https:\/\/falco.org\/docs\/getting-started\/falco-docker-quickstart\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/reference\/rules\/default-rules\/\">https:\/\/falco.org\/docs\/reference\/rules\/default-rules\/<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 6. Falco Rules &#8211; Fundamentals to Intermediate &#8211; 25 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Understand every essential field in a Falco YAML rule, use&nbsp;<code>evt.*<\/code>,&nbsp;<code>proc.*<\/code>,&nbsp;<code>fd.*<\/code>&nbsp;and&nbsp;<code>container.*<\/code>, and distinguish a rule from a macro and a list. The hands-on exercise explores your installed ruleset before you author your own.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The three YAML building blocks<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A&nbsp;<strong>rule<\/strong>&nbsp;evaluates an event and emits an alert if the condition is true. A&nbsp;<strong>macro<\/strong>&nbsp;stores a reusable condition fragment. A&nbsp;<strong>list<\/strong>&nbsp;stores reusable literal values (such as executable names). A rules file is a YAML list of entries, each starting with&nbsp;<code>- rule:<\/code>,&nbsp;<code>- macro:<\/code>&nbsp;or&nbsp;<code>- list:<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Example (for explanation; Chapter 7 will install a complete two-rule variant):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>- list: lab_shell_programs\n  items: &#91;bash, sh, dash]\n\n- macro: lab_process_execution_in_container\n  condition: evt.type in (execve, execveat) and container.id != host\n\n- rule: LAB Shell Started in Container\n  desc: Detect a shell program started in a test container.\n  condition: &gt;\n    lab_process_execution_in_container\n    and proc.name in (lab_shell_programs)\n  output: &gt;\n    LAB container shell started\n    process=%proc.name command=%proc.cmdline\n    user=%user.name container=%container.id\n  priority: NOTICE\n  tags: &#91;lab, container, process, mitre_execution, T1059]\n<\/code><\/pre>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">YAML field<\/th><th class=\"has-text-align-left\" data-align=\"left\">Meaning<\/th><th class=\"has-text-align-left\" data-align=\"left\">Required?<\/th><\/tr><\/thead><tbody><tr><td><code>rule<\/code><\/td><td>Unique human-readable name<\/td><td>Yes (rule entry)<\/td><\/tr><tr><td><code>desc<\/code><\/td><td>Human-readable detection description<\/td><td>Yes<\/td><\/tr><tr><td><code>condition<\/code><\/td><td>Boolean event-matching expression<\/td><td>Yes<\/td><\/tr><tr><td><code>output<\/code><\/td><td>What the alert should display, including&nbsp;<code>%field<\/code>&nbsp;placeholders<\/td><td>Yes<\/td><\/tr><tr><td><code>priority<\/code><\/td><td>Alert severity, aligned to syslog naming<\/td><td>Yes<\/td><\/tr><tr><td><code>tags<\/code><\/td><td>Searchable\/filterable classifications and mapping hints<\/td><td>No<\/td><\/tr><tr><td><code>enabled<\/code><\/td><td>Whether the rule is active<\/td><td>No; normally true<\/td><\/tr><tr><td><code>source<\/code><\/td><td>Event source, usually&nbsp;<code>syscall<\/code>&nbsp;by default<\/td><td>No<\/td><\/tr><tr><td><code>exceptions<\/code><\/td><td>Structured known-good behaviors excluded from alerting<\/td><td>No<\/td><\/tr><tr><td><code>append<\/code><\/td><td>Extend an existing rule\/macro\/list when supported<\/td><td>No<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>YAML syntax rules:<\/strong>&nbsp;Two-space indentation is easier to read. A dash introduces each list entry.&nbsp;<code>&gt;<\/code>&nbsp;folds multiple lines into a single logical string, useful for long conditions and outputs. Strings may be quoted to avoid YAML punctuation ambiguity. Never insert tabs for indentation.&nbsp;<code>condition<\/code>&nbsp;is a Falco expression,&nbsp;<strong>not<\/strong>&nbsp;Python, JavaScript, or a Linux shell command.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Understand the field families<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Family<\/th><th class=\"has-text-align-left\" data-align=\"left\">Example filter field<\/th><th class=\"has-text-align-left\" data-align=\"left\">Meaning<\/th><\/tr><\/thead><tbody><tr><td>Event<\/td><td><code>evt.type<\/code><\/td><td>Kernel event type, e.g.,&nbsp;<code>execve<\/code>&nbsp;or&nbsp;<code>openat<\/code><\/td><\/tr><tr><td>Event<\/td><td><code>evt.is_open_write<\/code><\/td><td>Whether an open operation was for writing<\/td><\/tr><tr><td>Event<\/td><td><code>evt.failed<\/code><\/td><td>Whether an event failed<\/td><\/tr><tr><td>Process<\/td><td><code>proc.name<\/code><\/td><td>Executable\/process name<\/td><\/tr><tr><td>Process<\/td><td><code>proc.cmdline<\/code><\/td><td>Command-line arguments (avoid exposing secrets unnecessarily)<\/td><\/tr><tr><td>Process<\/td><td><code>proc.pid<\/code><\/td><td>Process ID<\/td><\/tr><tr><td>Process<\/td><td><code>proc.pname<\/code><\/td><td>Parent process name<\/td><\/tr><tr><td>User<\/td><td><code>user.name<\/code><\/td><td>Username<\/td><\/tr><tr><td>File\/socket<\/td><td><code>fd.name<\/code><\/td><td>Full file path or socket descriptor representation<\/td><\/tr><tr><td>File\/socket<\/td><td><code>fd.directory<\/code><\/td><td>Directory of a file descriptor<\/td><\/tr><tr><td>Container<\/td><td><code>container.id<\/code><\/td><td>Container identifier, or&nbsp;<code>host<\/code>&nbsp;for host context<\/td><\/tr><tr><td>Container<\/td><td><code>container.name<\/code><\/td><td>Container name when metadata is available<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The field expression in a&nbsp;<strong>condition<\/strong>&nbsp;uses the field name, such as&nbsp;<code>proc.name = bash<\/code>. In&nbsp;<strong>output<\/strong>, prefix with&nbsp;<code>%<\/code>, such as&nbsp;<code>process=%proc.name<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Check what your version supports:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Every supported syscall event field, with names only<\/em>\nsudo falco --list=syscall -N | less\n\n<em># Broad list of installed rules and their descriptions<\/em>\nsudo falco -L | less\n\n<em># A specific available rule name can be inspected with -l<\/em>\nsudo falco -l 'Read sensitive file untrusted'\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The last name is used by some official rulesets; if your installed ruleset does not contain it, use a name returned by&nbsp;<code>falco -L<\/code>. There is no requirement that a particular upstream rule retain the same name forever.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Conditions and operators<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The commonly used operators include:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>=                Equal\n!=               Not equal\nin (...)         Value is in a set or Falco list\ncontains         Substring match\nstartswith       String prefix match\nand              Both expressions must match\nor               One expression must match\nnot              Logical negation\n(...)            Explicit evaluation precedence\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Example conditions:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># A process called bash or sh started in a container\nevt.type in (execve, execveat) and\ncontainer.id != host and\nproc.name in (bash, sh)\n\n# A file under \/etc was opened for writing\nevt.type in (open, openat, openat2) and\nevt.is_open_write=true and\nfd.name startswith \/etc\/\n\n# A process called python3 ran as root\nevt.type in (execve, execveat) and\nproc.name = python3 and\nuser.uid = 0\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Avoid unbounded rules<\/strong>, such as&nbsp;<code>proc.name != systemd<\/code>, that force evaluation over large numbers of unrelated events. The upstream style guide recommends positive&nbsp;<code>evt.type<\/code>&nbsp;clauses because event selection is an important efficiency technique. Use parentheses for mixed&nbsp;<code>and<\/code>\/<code>or<\/code>, e.g.,&nbsp;<code>evt.type in (execve, execveat) and (proc.name=bash or proc.name=sh)<\/code>. A rule can be syntactically valid yet still be operationally noisy or blind.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Rule priorities and tags<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Falco recognizes&nbsp;<code>EMERGENCY<\/code>,&nbsp;<code>ALERT<\/code>,&nbsp;<code>CRITICAL<\/code>,&nbsp;<code>ERROR<\/code>,&nbsp;<code>WARNING<\/code>,&nbsp;<code>NOTICE<\/code>,&nbsp;<code>INFORMATIONAL<\/code>, and&nbsp;<code>DEBUG<\/code>, ordered from most severe to least severe. Think of severity as&nbsp;<strong>triage guidance<\/strong>, not evidence of proven compromise.&nbsp;<code>ERROR<\/code>&nbsp;is often appropriate for unauthorized state-changing behavior, while&nbsp;<code>NOTICE<\/code>&nbsp;may be appropriate for unexpected but ambiguous actions.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>tags<\/code>&nbsp;are strings used to classify\/filter a rule. Common tags refer to container, filesystem, process, host, maturity or MITRE ATT&amp;CK tactics and techniques. Mapping a rule to&nbsp;<code>mitre_execution<\/code>&nbsp;and&nbsp;<code>T1059<\/code>&nbsp;helps analysts group detections. A tag is documentation\/classification; it does not magically change the event being captured.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Default rules vs local rules<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Default rules<\/strong>\u00a0are published by the Falco community and may be updated independently via\u00a0<code>falcoctl<\/code>\u00a0artifacts.<\/li>\n\n\n\n<li><strong>Local rules<\/strong>\u00a0belong to your environment and address workloads\/paths that upstream rules cannot know about.<\/li>\n\n\n\n<li><strong>Overrides and exceptions<\/strong>\u00a0refine existing rules. Changes should be reviewable and survive upgrades.<\/li>\n\n\n\n<li><strong>Rule ordering and overlapping matches<\/strong>\u00a0matter; more specific matching rules can be shadowed by broader earlier rules in some circumstances. Test the actual emitted alerts, not only whether YAML loads.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Never modify the vendor-supplied&nbsp;<code>falco_rules.yaml<\/code>&nbsp;directly as your standard workflow. Package and rule artifact updates can overwrite it. Store custom files in version control and deploy through a supported rules path, Helm values, or Operator&nbsp;<code>Rulesfile<\/code>&nbsp;resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Guided exercise: browse the ruleset<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Write the rule names\/descriptions to an analysis file in your home directory<\/em>\nsudo falco -L &gt; \"$HOME\/falco-default-rules.txt\"\n\n<em># Find likely shell, sensitive-file or filesystem protections<\/em>\ngrep -niE 'shell|sensitive|write below|container' \"$HOME\/falco-default-rules.txt\" | head -n 30\n\n<em># Explore the live rules file without editing it<\/em>\nsudo grep -nE '^&#91;-] (rule|macro|list):' \/etc\/falco\/falco_rules.yaml | head -n 35\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;you can locate several rule names, read a condition in the installed YAML, and identify at least one referenced macro\/list. If&nbsp;<code>falco -L<\/code>&nbsp;displays fewer names than expected, check which artifacts\/rule paths were loaded in the daemon&#8217;s configuration.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Knowledge check<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0What is the distinction between a list and a macro?\u00a0<strong>A:<\/strong>\u00a0A list holds values; a macro holds a condition expression.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Is\u00a0<code>proc.name=bash<\/code>\u00a0enough to detect suspicious shell use?\u00a0<strong>A:<\/strong>\u00a0Usually not; include event type and context.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Why specify\u00a0<code>evt.type<\/code>\u00a0positively?\u00a0<strong>A:<\/strong>\u00a0It helps select relevant events efficiently and avoids needlessly expensive matching.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0What do tags change?\u00a0<strong>A:<\/strong>\u00a0Classification\/filtering, not the underlying syscall or rule result.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Completion checkpoint:<\/strong>&nbsp;You can explain and read a rule, macro, list, output field, priority and MITRE tag before writing any custom code.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/\">https:\/\/falco.org\/docs\/concepts\/rules\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/basic-elements\/\">https:\/\/falco.org\/docs\/concepts\/rules\/basic-elements\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/style-guide\/\">https:\/\/falco.org\/docs\/concepts\/rules\/style-guide\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/rules\/supported-fields\/\">https:\/\/falco.org\/docs\/rules\/supported-fields\/<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 7. Writing and Testing Custom Falco Rules &#8211; 25 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Write a complete custom rules file, validate its syntax, deploy it, trigger two different behaviors, and debug a rule that does not fire. This is the most valuable beginner-to-intermediate lab.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">File layout for our project<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/falco\/\n`-- rules.d\/\n    `-- 90-falco-training.yaml   # Two complete custom detections\n\n\/tmp\/\n`-- falco-lab-protected.txt     # Safe mock sensitive file\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: create a standalone custom-rules file<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Ubuntu terminal;&nbsp;<code>sudo<\/code>&nbsp;required to write into&nbsp;<code>\/etc\/falco\/rules.d<\/code>:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Ensure rules.d exists (some installations create it automatically)<\/em>\nsudo install -d -m 0755 \/etc\/falco\/rules.d\n\n<em># Copy-ready rules: creates both a shell detection and a controlled file-write detection<\/em>\nsudo tee \/etc\/falco\/rules.d\/90-falco-training.yaml &gt; \/dev\/null &lt;&lt;'YAML'\n- list: lab_shell_binaries\n  items: &#91;bash, sh, dash]\n\n- macro: lab_shell_exec_in_container\n  condition: &gt;\n    evt.type in (execve, execveat)\n    and container.id != host\n\n- rule: LAB Shell Started in Container\n  desc: Detect the execution of a shell program inside a Linux test container.\n  condition: &gt;\n    lab_shell_exec_in_container\n    and proc.name in (lab_shell_binaries)\n  output: &gt;\n    LAB shell started in container\n    process=%proc.name command=%proc.cmdline\n    user=%user.name container_id=%container.id container_name=%container.name\n  priority: NOTICE\n  tags: &#91;lab, container, process, mitre_execution, T1059]\n\n- rule: LAB Protected File Opened for Writing\n  desc: Detect a write-open operation on a harmless mock sensitive file in \/tmp.\n  condition: &gt;\n    evt.type in (open, openat, openat2)\n    and evt.is_open_write=true\n    and fd.name = \/tmp\/falco-lab-protected.txt\n  output: &gt;\n    LAB protected file opened for writing\n    file=%fd.name process=%proc.name\n    user=%user.name pid=%proc.pid command=%proc.cmdline\n  priority: WARNING\n  tags: &#91;lab, filesystem, file_access]\nYAML\n\n<em># Display the saved file to confirm every line was written<\/em>\nsudo sed -n '1,100p' \/etc\/falco\/rules.d\/90-falco-training.yaml\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Why these specific conditions?<\/strong>&nbsp;The process rule selects execution syscalls and only container contexts, then requires a shell executable. The file rule selects open\/openat\/openat2 events, requires a write-open flag, and targets one harmless absolute filename. Neither rule searches every event or operates on actual sensitive system data.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: validate before applying<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Validate all required default rules plus our standalone lab rule file.<\/em>\n<em># If your installed config has different rule paths, use those paths instead.<\/em>\nsudo falco -V \/etc\/falco\/falco_rules.yaml \\\n  -V \/etc\/falco\/rules.d\/90-falco-training.yaml\n\n<em># Validate the live configuration and its selected rules files<\/em>\nsudo falco --dry-run -c \/etc\/falco\/falco.yaml\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;Falco returns an exit code of zero and no rule-loading validation errors.&nbsp;<code>-V<\/code>&nbsp;validates the specified rules files and exits;&nbsp;<code>--dry-run<\/code>&nbsp;verifies configuration\/rule setup without consuming kernel events. If a macro or list referenced by your rule is in another file, include that dependency during validation. Our lab macro\/list are self-contained.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If validation reports&nbsp;<code>unexpected key<\/code>,&nbsp;<code>unknown filtercheck<\/code>,&nbsp;<code>invalid syntax<\/code>, or a YAML mapping error, compare indentation, rule names and Falco&#8217;s version-specific supported fields. A parser accepting YAML is not enough: Falco must also accept the&nbsp;<strong>Falco expression language<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: check rule search path, then load changes<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Confirm your live config includes rules.d (either directly or through another file)<\/em>\nsudo grep -n -A8 '^rules_files:' \/etc\/falco\/falco.yaml\n\n<em># Restart the appropriate test host daemon to ensure rules reload<\/em>\nsudo systemctl restart falco-modern-bpf.service\n\n<em># Verify startup and identify whether the custom rules file was loaded<\/em>\nsudo systemctl is-active falco-modern-bpf.service\nsudo journalctl -u falco-modern-bpf.service -n 100 --no-pager | \\\n  grep -iE 'rules|90-falco-training|error|warning'\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">If&nbsp;<code>rules.d<\/code>&nbsp;is not in the selected rule files, add the directory to&nbsp;<code>rules_files<\/code>&nbsp;in a safely reviewed copy of the config, then validate again.&nbsp;<strong>Do not<\/strong>&nbsp;assume merely creating a file makes Falco consume it. Restarting the daemon can briefly interrupt event collection; this is acceptable only in a disposable lab. Production uses a controlled rollout\/reload strategy.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: trigger the file-write rule (most deterministic first)<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Terminal A:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo journalctl -fu falco-modern-bpf.service\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Terminal B:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Create\/open precisely the protected mock file for writing<\/em>\nprintf 'LAB write 1\\n' &gt; \/tmp\/falco-lab-protected.txt\n\n<em># Append a second line (another write-open operation)<\/em>\nprintf 'LAB write 2\\n' &gt;&gt; \/tmp\/falco-lab-protected.txt\n\n<em># Verify contents; reading the file should NOT satisfy the write-open rule<\/em>\ncat \/tmp\/falco-lab-protected.txt\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;one or more&nbsp;<code>LAB Protected File Opened for Writing<\/code>&nbsp;alerts. The exact process name can be the shell itself because redirection is performed by the shell. If a different path is resolved due to mount namespaces or redirection behavior, check&nbsp;<code>fd.name<\/code>&nbsp;in diagnostic logs and confirm that the rule path exactly matches the actual path.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Negative test (important):<\/strong>&nbsp;<code>cat \/tmp\/falco-lab-protected.txt<\/code>&nbsp;must not trigger the&nbsp;<strong>write-open<\/strong>&nbsp;rule (it could independently trigger other enabled rules). A useful rule is validated by both a positive trigger and a negative control.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: trigger shell execution in a container<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Terminal B:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Docker must run on the Linux host observed by Falco<\/em>\nsudo docker run --rm --name falco-shell-test ubuntu:24.04 \\\n  bash -c 'echo custom-shell-rule-test; id'\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;a&nbsp;<code>LAB Shell Started in Container<\/code>&nbsp;notice&nbsp;<strong>if<\/strong>&nbsp;the rule is loaded, the container metadata event is recognized, and the shell execution is not preempted by an earlier more general rule. If you see a different default shell rule, that is evidence that detection is operational, but you still need to validate your own rule separately. Refer to the next diagnostic procedure.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: troubleshoot a rule that fails to trigger<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Debug in this order:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Source:<\/strong>\u00a0Is the process actually running on this Linux kernel?\u00a0<code>sudo docker info<\/code>,\u00a0<code>uname -r<\/code>.<\/li>\n\n\n\n<li><strong>Daemon:<\/strong>\u00a0Is Falco active?\u00a0<code>sudo systemctl is-active falco-modern-bpf.service<\/code>.<\/li>\n\n\n\n<li><strong>Loaded rules:<\/strong>\u00a0Did startup mention\u00a0<code>90-falco-training.yaml<\/code>? Check\u00a0<code>rules_files<\/code>\u00a0and journal logs.<\/li>\n\n\n\n<li><strong>Syntax:<\/strong>\u00a0Does\u00a0<code>falco -V<\/code>\u00a0succeed with the required dependencies?<\/li>\n\n\n\n<li><strong>Event filters:<\/strong>\u00a0Is the event type correct (<code>execve<\/code>\/<code>execveat<\/code>, open\/openat\/openat2)? Are you looking at successful vs failed events?<\/li>\n\n\n\n<li><strong>Context:<\/strong>\u00a0Does\u00a0<code>container.id<\/code>\u00a0equal\u00a0<code>host<\/code>\u00a0unexpectedly? Is the container plugin providing metadata? Does\u00a0<code>fd.name<\/code>\u00a0match the path?<\/li>\n\n\n\n<li><strong>Ordering:<\/strong>\u00a0Is a broader earlier rule matching the same events? Review matching rules and load order.<\/li>\n\n\n\n<li><strong>Output:<\/strong>\u00a0Are alerts going to stdout\/syslog\/HTTP while you are watching another destination?<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Optional advanced isolation test (only on the disposable Ubuntu VM):<\/strong>&nbsp;Stop the host service temporarily and run Falco with&nbsp;<strong>only your custom rules<\/strong>&nbsp;in a foreground terminal. This separates your rule logic from overlapping default rules, but is an operational change; do not do it on a shared monitored host.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Terminal A: temporarily stop the test service, then run a dedicated test ruleset<\/em>\nsudo systemctl stop falco-modern-bpf.service\nsudo falco -c \/etc\/falco\/falco.yaml \\\n  -r \/etc\/falco\/rules.d\/90-falco-training.yaml \\\n  -o engine.kind=modern_ebpf \\\n  -o stdout_output.enabled=true\n\n<em># Terminal B: repeat the Docker and mock-file lab triggers above.<\/em>\n<em># Terminal A: press Ctrl-C to stop foreground Falco when finished.<\/em>\n\n<em># Restore normal monitored service afterward (Ubuntu terminal)<\/em>\nsudo systemctl start falco-modern-bpf.service\nsudo systemctl is-active falco-modern-bpf.service\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">If the foreground test fails to start, review its error text rather than repeatedly restarting. This method still relies on your installed configuration&#8217;s plugin and engine settings. It is not guaranteed to reconstruct container metadata if plugins are absent.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: how an intermediate engineer improves the rule<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">For a real workload, ask these questions before shipping:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Which container image or Kubernetes namespace is allowed to run this shell, if any?<\/li>\n\n\n\n<li>Should only interactive shells be suspicious, or also programmatic shells?<\/li>\n\n\n\n<li>Should the rule ignore a known maintenance job but still alert for all other workloads?<\/li>\n\n\n\n<li>Is\u00a0<code>proc.name<\/code>\u00a0stable enough, or should you also inspect executable path, parent process, command or container image?<\/li>\n\n\n\n<li>Can a malicious user avoid this rule by launching a different interpreter, direct syscalls or a renamed executable?<\/li>\n\n\n\n<li>How many legitimate alerts per day appear during a staging observation window?<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Production sample:<\/strong>&nbsp;A Go or Java application container unexpectedly launching&nbsp;<code>bash<\/code>&nbsp;is often more noteworthy than a CI runner container designed to execute shell scripts. The intermediate skill is writing the same syscall rule but applying workload-specific policy and meaningful exceptions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: cleanup and rollback<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Remove the mock data file (the rule remains installed for further chapters)<\/em>\nrm -f \/tmp\/falco-lab-protected.txt\n\n<em># Optional: remove lab rules and return to a default-rules host<\/em>\n<em># WARNING: this removes the two training detections created in this chapter.<\/em>\n<em># sudo rm -f \/etc\/falco\/rules.d\/90-falco-training.yaml<\/em>\n<em># sudo systemctl restart falco-modern-bpf.service<\/em>\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">For most learners,&nbsp;<strong>keep<\/strong>&nbsp;<code>90-falco-training.yaml<\/code>&nbsp;until completing Chapter 10, because it will be used to practice exceptions. Source-control the custom file and keep your human-written rule changes separate from the automatically updated upstream rules.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Knowledge check<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0Why test a negative case?\u00a0<strong>A:<\/strong>\u00a0To confirm a rule excludes non-targeted behavior, not merely that some alert exists.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Why validate configuration and rules before restarting?\u00a0<strong>A:<\/strong>\u00a0To catch parser\/configuration errors without interrupting monitoring.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Why might a custom rule not fire despite valid YAML?\u00a0<strong>A:<\/strong>\u00a0The event\/field\/context does not match, the file is not loaded, another rule takes precedence, or the output is not observed.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Why not build the lab on\u00a0<code>\/etc\/shadow<\/code>\u00a0writes?\u00a0<strong>A:<\/strong>\u00a0Real system files are sensitive and modification risks harming the host; a mock path is enough to prove detection logic.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Completion checkpoint:<\/strong>&nbsp;You have authored a rules file, validated it, loaded it, tested a true and false case, and can explain a debugging sequence.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/custom-ruleset\/\">https:\/\/falco.org\/docs\/concepts\/rules\/custom-ruleset\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/reference\/daemon\/cli-arguments\/\">https:\/\/falco.org\/docs\/reference\/daemon\/cli-arguments\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/conditions\/\">https:\/\/falco.org\/docs\/concepts\/rules\/conditions\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/style-guide\/\">https:\/\/falco.org\/docs\/concepts\/rules\/style-guide\/<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 8. Falco Alerts and Integrations &#8211; 10 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Understand alert transports, switch between text\/JSON formats, learn Falcosidekick&#8217;s function, and identify safe integration patterns for Slack, SIEM and monitoring tools.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">From event to alert to integration<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>flowchart LR\n    A&#91;Falco rule match] --&gt; B&#91;Priority and structured output]\n    B --&gt; C&#91;stdout or file]\n    B --&gt; D&#91;Syslog \/ journald]\n    B --&gt; E&#91;HTTP\/HTTPS]\n    E --&gt; F&#91;Falcosidekick]\n    F --&gt; G&#91;Slack \/ Teams \/ Chat]\n    F --&gt; H&#91;SIEM and log systems]\n    F --&gt; I&#91;Prometheus \/ Datadog \/ alerting]\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Falco supports standard output, file output, syslog, spawned program output, and HTTP\/HTTPS output.&nbsp;<strong>Falco gRPC output is no longer available in 0.45.0<\/strong>&nbsp;(removed in 0.44.0), so avoid older examples centered on it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Plain text vs JSON output<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Text is human-friendly, while JSON is machine-friendly. A simplified&nbsp;<strong>illustrative<\/strong>&nbsp;JSON alert (keys from the official JSON output format) might look like:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>{\n  \"time\": \"2026-10-11T02:30:00.000000000Z\",\n  \"rule\": \"LAB Protected File Opened for Writing\",\n  \"priority\": \"Warning\",\n  \"output\": \"LAB protected file opened for writing file=\/tmp\/falco-lab-protected.txt\",\n  \"hostname\": \"ubuntu-lab\",\n  \"tags\": &#91;\"lab\", \"filesystem\"],\n  \"output_fields\": {\n    \"fd.name\": \"\/tmp\/falco-lab-protected.txt\",\n    \"proc.name\": \"bash\",\n    \"user.name\": \"ubuntu\"\n  }\n}\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The illustration is not the exact JSON produced by every release\/rule; the real values and fields depend on the rule&#8217;s&nbsp;<code>output<\/code>&nbsp;placeholders and available plugin fields. The official documented keys include&nbsp;<code>time<\/code>,&nbsp;<code>rule<\/code>,&nbsp;<code>priority<\/code>,&nbsp;<code>output<\/code>,&nbsp;<code>hostname<\/code>,&nbsp;<code>tags<\/code>&nbsp;and&nbsp;<code>output_fields<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab: enable JSON in an isolated foreground run<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Do not start a second competing Falco process against a shared\/production host.<\/strong>&nbsp;On the disposable Ubuntu VM, use the isolation procedure from Chapter 7:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Terminal A, training VM only<\/em>\nsudo systemctl stop falco-modern-bpf.service\nsudo falco -c \/etc\/falco\/falco.yaml \\\n  -r \/etc\/falco\/rules.d\/90-falco-training.yaml \\\n  -o engine.kind=modern_ebpf \\\n  -o json_output=true \\\n  -o stdout_output.enabled=true\n\n<em># Terminal B: safely trigger one custom rule<\/em>\nprintf 'JSON test\\n' &gt;&gt; \/tmp\/falco-lab-protected.txt\n\n<em># Read a JSON object in Terminal A; Ctrl-C to exit foreground Falco.<\/em>\n<em># Restore the service when the test is finished.<\/em>\nsudo systemctl start falco-modern-bpf.service\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;the same rule name and event context now appear as JSON, generally one JSON object per alert line. You may optionally pipe captured JSON lines into&nbsp;<code>jq<\/code>&nbsp;for analysis once the format is configured, but do not assume all journald messages are pure JSON (daemon startup notices often are not).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Falcosidekick: a forwarder, not an additional kernel monitor<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Falcosidekick accepts Falco alerts via HTTP and forwards them to configured destinations. It can add fields, filter by priorities and expose useful metrics. It is a delivery layer:&nbsp;<strong>Falco detects; Falcosidekick routes; the receiving system stores, visualizes or triggers action<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A typical&nbsp;<strong>Kubernetes-side configuration concept<\/strong>&nbsp;is:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Falco configuration fragment only; not a complete replacement falco.yaml<\/em>\njson_output: true\nhttp_output:\n  enabled: true\n  url: http:\/\/falco-falcosidekick.falco.svc.cluster.local:2801\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The exact service name depends on your Helm\/Operator release, namespace and chart configuration. Check&nbsp;<code>kubectl get svc -n falco<\/code>&nbsp;before committing a URL. Use only authorized, TLS-protected endpoints across trust boundaries; HTTP may be acceptable inside a narrowly scoped local lab but is not a general recommendation for untrusted networks.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Quick chart-based lab integration<\/strong>&nbsp;(only if you used Helm deployment in Chapter 9):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Deploy the chart's optional Falcosidekick component with Falco<\/em>\nhelm upgrade falco falcosecurity\/falco \\\n  --namespace falco \\\n  --set falcosidekick.enabled=true \\\n  --set tty=true\n\n<em># Look for sidekick service and pod names before checking logs<\/em>\nkubectl get pods,svc -n falco\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Warning: a&nbsp;<code>helm upgrade<\/code>&nbsp;with only these flags can drop previous CLI-only customizations; for real deployments use a checked-in values file and&nbsp;<code>helm get values -n falco falco -a<\/code>&nbsp;to preserve desired state. Validate the currently installed chart version and supported keys before use. Do not create Slack\/Datadog credentials merely for this study exercise.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Integration patterns and guardrails<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Destination<\/th><th class=\"has-text-align-left\" data-align=\"left\">Why use it<\/th><th class=\"has-text-align-left\" data-align=\"left\">Careful about<\/th><\/tr><\/thead><tbody><tr><td>Local journal\/stdout<\/td><td>First lab and direct troubleshooting<\/td><td>Journal retention and access<\/td><\/tr><tr><td>Falcosidekick -&gt; Slack\/Teams<\/td><td>Operational awareness<\/td><td>Rate limits, alert noise, webhook secrets<\/td><\/tr><tr><td>Falcosidekick -&gt; SIEM<\/td><td>Correlation, long-term investigation<\/td><td>Field normalization, TLS, identity, retention<\/td><\/tr><tr><td>Falcosidekick -&gt; Datadog\/Prometheus<\/td><td>Operational views and monitoring<\/td><td>Distinguish Falco alerts from sensor health counters<\/td><\/tr><tr><td>Custom incident response automation<\/td><td>Enrichment, tickets, containment<\/td><td>Explicit approvals, safeguards and rollback<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Security note:<\/strong>&nbsp;Falco outputs can contain filenames, usernames, commands and arguments; command arguments sometimes include tokens or credentials. Treat alert streams as security-sensitive telemetry. Use authorization, secret stores, transport security, sensible retention and redaction where practical. Never paste actual webhook tokens into a tutorial or into a Kubernetes ConfigMap in plaintext.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Knowledge check<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0Does JSON change the rule condition?\u00a0<strong>A:<\/strong>\u00a0No; it changes how the alert is represented.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Does Falcosidekick read kernel syscalls directly?\u00a0<strong>A:<\/strong>\u00a0No; it forwards alerts produced by Falco.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Can the 2026 Falco engine use gRPC output examples from old tutorials?\u00a0<strong>A:<\/strong>\u00a0Not on the 0.45.0 release.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Completion checkpoint:<\/strong>&nbsp;You can find alerts in logs, recognize JSON fields and describe how to safely forward alerts.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/outputs\/\">https:\/\/falco.org\/docs\/concepts\/outputs\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/outputs\/channels\/\">https:\/\/falco.org\/docs\/concepts\/outputs\/channels\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/outputs\/forwarding\/\">https:\/\/falco.org\/docs\/concepts\/outputs\/forwarding\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/blog\/falco-0-44-0\/\">https:\/\/falco.org\/blog\/falco-0-44-0\/<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 9. Falco with Kubernetes &#8211; 20 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Understand the node-level DaemonSet model; deploy Falco using the fast Helm lab method; inspect a pod-generated alert; and learn the current operator-based management model. Also understand how Kubernetes metadata joins a syscall event.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisites and operational boundaries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An\u00a0<strong>authorized Kubernetes test cluster<\/strong>\u00a0with Linux worker nodes, not a production cluster.<\/li>\n\n\n\n<li>The cluster nodes must support the chosen Falco sensor&#8217;s kernel features\/privileges.<\/li>\n\n\n\n<li><code>kubectl<\/code>\u00a0configured to the intended context;\u00a0<code>helm<\/code>\u00a0installed locally.<\/li>\n\n\n\n<li>Permissions to create namespaces, DaemonSets, ServiceAccounts, roles and potentially privileged pods. For the operator, Kubernetes\u00a0<strong>1.29+<\/strong>\u00a0is required by the official guide.<\/li>\n\n\n\n<li>A network path for pulling chart images and rule artifacts.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Host platform distinction:<\/strong>&nbsp;Helm and kubectl can run on Windows, macOS or Ubuntu because they are remote cluster administration clients. Falco itself runs on the cluster&#8217;s Linux workers. Docker Desktop Kubernetes on macOS\/Windows is not the official Linux-node Falco lab target; use a suitable test Linux-node cluster instead.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Preflight in the terminal where kubectl is configured:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Confirm the intended cluster and current context before installing anything<\/em>\nkubectl config current-context\nkubectl cluster-info\nkubectl get nodes -o wide\nkubectl auth can-i create daemonsets -n kube-system\n\n<em># Verify the CLI dependencies are installed<\/em>\nkubectl version --client\nhelm version\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Do not proceed if the context unexpectedly points at production. The DaemonSet experiment grants deep node visibility and must pass your organization&#8217;s security review when performed outside an isolated lab.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Kubernetes architecture<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>flowchart TD\n    K&#91;Kubernetes API server] --&gt; M&#91;Workload \/ Pod metadata]\n    S&#91;Node 1: application pods] --&gt; F1&#91;Node 1: Falco sensor pod]\n    T&#91;Node 2: application pods] --&gt; F2&#91;Node 2: Falco sensor pod]\n    F1 --&gt; R&#91;Falco rule matches]\n    F2 --&gt; R\n    M --&gt; P&#91;k8s metadata plugin + collector if configured]\n    P --&gt; R\n    R --&gt; O&#91;Logs \/ Falcosidekick \/ SIEM]\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Each node-level Falco instance observes Linux events on its node. Workload metadata may be attached by the container plugin and, when configured, the Kubernetes metadata plugin\/collector. Kubernetes API audit events require a different plugin\/source integration; simply running Falco as a DaemonSet does&nbsp;<strong>not<\/strong>&nbsp;automatically ingest all API audit records.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Deployment choice in October 2026<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Falco Operator is the officially recommended management model<\/strong>&nbsp;as of 2026, with&nbsp;<code>Falco<\/code>,&nbsp;<code>Rulesfile<\/code>,&nbsp;<code>Plugin<\/code>,&nbsp;<code>Config<\/code>&nbsp;and&nbsp;<code>Component<\/code>&nbsp;custom resources (CRDs). The classic Falco Helm chart remains supported and is simpler for a short training lab. Both should be understood; do&nbsp;<strong>one<\/strong>&nbsp;primary installation on a test cluster, not two overlapping copies.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Choice<\/th><th class=\"has-text-align-left\" data-align=\"left\">Advantages<\/th><th class=\"has-text-align-left\" data-align=\"left\">Use in this guide<\/th><\/tr><\/thead><tbody><tr><td>Falco Helm chart<\/td><td>Short install, easy start, broad familiarity<\/td><td><strong>Core 20-minute lab<\/strong><\/td><\/tr><tr><td>Falco Operator<\/td><td>Declarative management of instances, rules, plugins and configurations<\/td><td>Intermediate extension and preferred long-term design<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Path A: Core 20-minute lab using the supported Falco Helm chart<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Step A1: install Falco<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Register the official Falco Helm charts repository<\/em>\nhelm repo add falcosecurity https:\/\/falcosecurity.github.io\/charts\nhelm repo update\n\n<em># Inspect the chart version available in your current repository<\/em>\nhelm show chart falcosecurity\/falco | head -n 30\n\n<em># Install into a separate namespace<\/em>\nhelm install falco falcosecurity\/falco \\\n  --namespace falco --create-namespace --set tty=true\n\n<em># Inspect release and DaemonSet placement<\/em>\nhelm list -n falco\nkubectl get daemonsets,pods -n falco -o wide\n\n<em># Wait for the Falco pods to be ready<\/em>\nkubectl wait pods --for=condition=Ready --all -n falco --timeout=180s\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;the number of ready Falco DaemonSet pods reflects schedulable, supported nodes, subject to chart scheduling\/tolerations and DaemonSet rules. One falco pod per compatible node is the usual design, not a general guarantee. If pods remain Pending, inspect scheduling, privileges, kernel compatibility, image pull access and tolerations.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Troubleshooting commands:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl get events -n falco --sort-by=.lastTimestamp | tail -n 25\nkubectl describe daemonset -n falco falco\nkubectl get pods -n falco -o wide\nkubectl logs -n falco -l app.kubernetes.io\/name=falco -c falco --since=10m --prefix=true\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Depending on the chart and deployment flags, the daemonset\/pod\/label names may differ. Read&nbsp;<code>helm list<\/code>,&nbsp;<code>kubectl get ds -n falco<\/code>&nbsp;and actual pod labels rather than blindly using the name&nbsp;<code>falco<\/code>&nbsp;for everything.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step A2: deploy one harmless workload<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Isolate the demonstration application from existing namespaces<\/em>\nkubectl create namespace falco-lab\n\n<em># Create a single small web server for triggering a controlled event<\/em>\nkubectl -n falco-lab create deployment nginx --image=nginx:stable\n\n<em># Wait until its pod is ready<\/em>\nkubectl -n falco-lab wait --for=condition=Ready pod \\\n  -l app=nginx --timeout=180s\n\n<em># Inspect the assigned node so you can correlate it with one Falco pod<\/em>\nkubectl -n falco-lab get pods -l app=nginx -o wide\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step A3: generate a sensitive-file read in the test pod<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Execute this command ONLY against the demo workload in the test namespace.<\/em>\n<em># It reads a sensitive file without printing it to your terminal.<\/em>\nkubectl -n falco-lab exec deployment\/nginx -- \\\n  sh -c 'cat \/etc\/shadow &gt; \/dev\/null'\n\n<em># Search recent Falco pod logs for any matching sensitivity alert<\/em>\nkubectl -n falco logs -l app.kubernetes.io\/name=falco \\\n  -c falco --since=10m --prefix=true | \\\n  grep -iE 'sensitive|shadow|warning'\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;an alert from the Falco pod running on the same node as the&nbsp;<code>nginx<\/code>&nbsp;pod, if the corresponding default rule is loaded. The output may contain&nbsp;<code>container_id<\/code>,&nbsp;<code>container_image<\/code>, and potentially&nbsp;<code>k8s_ns<\/code>\/<code>k8s_pod_name<\/code>&nbsp;if the enrichment integration is configured. Some image variants or security policies may block reading&nbsp;<code>\/etc\/shadow<\/code>; that failure itself is not proof of a Falco problem. The base nginx image might also vary over time. If&nbsp;<code>cat<\/code>&nbsp;is absent, use an image with the necessary utility and keep the exercise on an isolated test namespace.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>If you receive no alert:<\/strong>&nbsp;check Falco startup\/rule logs, target node scheduling, ruleset maturity\/enablement, container runtime socket and metadata plugin, and whether your query includes the right namespace\/pod. The default ruleset may change; a dedicated custom detection removes uncertainty.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step A4: add a custom rule with Helm values<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The official chart supports the&nbsp;<code>customRules<\/code>&nbsp;value. Save this complete values file on the machine running Helm:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat &gt; falco-custom-values.yaml &lt;&lt;'YAML'\ncustomRules:\n  custom-lab.yaml: |-\n    - rule: LAB Kubernetes Shell Exec\n      desc: Detect shell execution inside a test Kubernetes container.\n      condition: &gt;\n        evt.type in (execve, execveat)\n        and container.id != host\n        and proc.name in (bash, sh)\n      output: &gt;\n        LAB Kubernetes container shell started\n        process=%proc.name user=%user.name\n        container=%container.id command=%proc.cmdline\n      priority: NOTICE\n      tags: &#91;lab, kubernetes, container, mitre_execution, T1059]\nYAML\n\n<em># Apply the custom-rule settings to the existing Helm release<\/em>\nhelm upgrade falco falcosecurity\/falco \\\n  --namespace falco -f falco-custom-values.yaml --set tty=true\n\n<em># Wait for the chart components to settle<\/em>\nkubectl -n falco get pods\nkubectl -n falco wait pods --for=condition=Ready --all --timeout=180s\n\n<em># Trigger shell execution from the lab workload and review alerts<\/em>\nkubectl -n falco-lab exec deployment\/nginx -- sh -c 'echo shell-lab'\nkubectl -n falco logs -l app.kubernetes.io\/name=falco \\\n  -c falco --since=10m --prefix=true | grep 'LAB Kubernetes'\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Why this matters:<\/strong>&nbsp;the Helm chart packages the custom YAML into a Kubernetes ConfigMap and makes it available to Falco. In production, preserve your complete approved values file instead of repeatedly adding independent CLI&nbsp;<code>--set<\/code>&nbsp;options. The exact upgrade behavior of existing values should be tested and reviewed for your chart version.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step A5: clean up only resources from this lab<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Deletes the demonstration nginx deployment and namespace<\/em>\nkubectl delete namespace falco-lab\n\n<em># Removes the Falco Helm release (node monitoring stops)<\/em>\nhelm uninstall falco -n falco\n\n<em># Optional: remove its now-empty namespace after verifying contents<\/em>\nkubectl delete namespace falco\n\n<em># Remove the local chart override file if not needed<\/em>\nrm -f falco-custom-values.yaml\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Impact:<\/strong>&nbsp;uninstalling Falco stops monitoring the test cluster. Never apply cleanup to a shared cluster that relies on this Falco release for security coverage.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Path B: Intermediate extension &#8211; recommended Falco Operator<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is an&nbsp;<strong>alternative deployment<\/strong>; use on a clean test cluster or after cleaning up Path A. The Operator manages Falco as Kubernetes custom resources. For current operator releases, inspect&nbsp;<code>helm show chart ...<\/code>&nbsp;and the&nbsp;<a href=\"https:\/\/github.com\/falcosecurity\/falco-operator\/blob\/main\/docs\/version-matrix.md\">operator version matrix<\/a>: the default deployed Falco binary can lag the newest Falco engine unless you explicitly pin or update it.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Install the operator controller and its CRDs<\/em>\nhelm repo add falcosecurity https:\/\/falcosecurity.github.io\/charts\nhelm repo update\nhelm show chart falcosecurity\/falco-operator | head -n 30\nhelm install falco-operator falcosecurity\/falco-operator \\\n  --namespace falco-operator --create-namespace\n\n<em># Check controller health<\/em>\nkubectl wait pods -n falco-operator \\\n  --for=condition=Ready --all --timeout=180s\n\n<em># Create a dedicated namespace for Falco instances and artifacts<\/em>\nkubectl create namespace falco\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Create the Falco instance<\/strong>&nbsp;(run from a Bash-compatible shell with kubectl context set):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat &lt;&lt;'YAML' | kubectl apply -n falco -f -\napiVersion: instance.falcosecurity.dev\/v1alpha1\nkind: Falco\nmetadata:\n  name: falco\nspec: {}\nYAML\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Install the container enrichment plugin<\/strong>&nbsp;(required for several default&nbsp;<code>container.*<\/code>&nbsp;fields):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat &lt;&lt;'YAML' | kubectl apply -n falco -f -\napiVersion: artifact.falcosecurity.dev\/v1alpha1\nkind: Plugin\nmetadata:\n  name: container\nspec:\n  ociArtifact:\n    image:\n      repository: falcosecurity\/plugins\/plugin\/container\n      tag: latest\n    registry:\n      name: ghcr.io\nYAML\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Install the official rules artifact<\/strong>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat &lt;&lt;'YAML' | kubectl apply -n falco -f -\napiVersion: artifact.falcosecurity.dev\/v1alpha1\nkind: Rulesfile\nmetadata:\n  name: falco-rules\nspec:\n  ociArtifact:\n    image:\n      repository: falcosecurity\/rules\/falco-rules\n      tag: latest\n    registry:\n      name: ghcr.io\n  priority: 50\nYAML\n\n<em># Verify reconciliation and workload status<\/em>\nkubectl get falco,plugins,rulesfiles,configs,components -n falco\nkubectl get pods -n falco -o wide\nkubectl get daemonsets -n falco -o wide\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;Falco instance, plugin and rules artifact resources become reconciled and available. Do not omit plugin\/rules setup in a manual Operator install: the Falco instance alone can run without the rule content needed to generate useful alerts. The official alternative&nbsp;<strong>full-stack quickstart<\/strong>&nbsp;includes the k8smeta plugin, metadata collector, Falcosidekick and UI; see the official operator guide for exact deployment and cleanup procedures.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Inspect actual Falco image version:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Inspect the running image. This is crucial because Operator defaults can lag Falco releases.<\/em>\nkubectl get daemonsets -n falco \\\n  -o jsonpath='{range .items&#91;*]}{.metadata.name}{\" -&gt; \"}{.spec.template.spec.containers&#91;*].image}{\"\\n\"}{end}'\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">For real environments, verify and pin both operator\/chart and Falco engine versions in tested configuration, and update the deployment per supported CRD API rather than assuming&nbsp;<code>latest<\/code>&nbsp;always means Falco 0.45.0.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Operator removal, lab only:<\/strong>&nbsp;delete&nbsp;<code>Rulesfile<\/code>,&nbsp;<code>Plugin<\/code>, and&nbsp;<code>Config<\/code>&nbsp;objects&nbsp;<strong>before<\/strong>&nbsp;deleting the Falco instance. Then delete remaining&nbsp;<code>Component<\/code>&nbsp;resources and the operator Helm release, following the official ordered removal guide. Be especially cautious with operator CRDs: deleting a CRD removes every custom resource of that type, so do not do it in a shared cluster.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Kubernetes metadata: what is and is not automatic<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A process-level event starts with the&nbsp;<strong>node<\/strong>, and a container ID can be associated with a container runtime. Kubernetes namespace, pod and workload details may require&nbsp;<code>k8smeta<\/code>&nbsp;and its collector (or another supported metadata setup). If&nbsp;<code>k8s.pod.*<\/code>&nbsp;or Kubernetes output fields display&nbsp;<code>&lt;NA&gt;<\/code>, verify enrichment rather than claiming that Falco cannot see any syscalls. Also distinguish&nbsp;<strong>Kubernetes API audit-log ingestion<\/strong>&nbsp;from Kubernetes workload metadata enrichment; these are separate functions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Production guardrails (intermediate)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Validate compatibility with your exact node OS, kernel, runtime, managed-service constraints and privilege policy.<\/li>\n\n\n\n<li>Confirm one sensor is scheduled on each node type you intend to monitor; use tolerations\/node selectors carefully.<\/li>\n\n\n\n<li>Check that privileged DaemonSets are allowed and can load modern eBPF, or plan a supported alternative architecture.<\/li>\n\n\n\n<li>Do not assume Amazon EKS Auto Mode, Fargate or another managed\/abstracted compute mode supports every privileged host-level DaemonSet. Validate with vendor documentation and a staging proof-of-concept; these environments have different node control restrictions.<\/li>\n\n\n\n<li>Plan immutable-version upgrades, metadata plugin availability, secret handling, node reboots, cost and event\/drop metrics.<\/li>\n\n\n\n<li>Distinguish kube-system infrastructure noise from application workload detections; tune only after observing the workload baseline.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Knowledge check<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0Why does Falco normally run as a DaemonSet?\u00a0<strong>A:<\/strong>\u00a0It captures per-node Linux events; a node-local sensor is needed for workloads on that node.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0What is the currently preferred Kubernetes management path?\u00a0<strong>A:<\/strong>\u00a0The Falco Operator, with Helm still supported.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Does loading the container plugin automatically mean Kubernetes API audit events are ingested?\u00a0<strong>A:<\/strong>\u00a0No.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Why inspect the actual image version after installing the operator?\u00a0<strong>A:<\/strong>\u00a0The operator&#8217;s default Falco engine version may differ from the newest upstream release.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Completion checkpoint:<\/strong>&nbsp;You can install and verify a Falco DaemonSet on a Linux-node test cluster, trigger a pod-related event, find the correct sensor logs, and explain the Operator&#8217;s custom-resource model.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/getting-started\/falco-kubernetes-quickstart\/\">https:\/\/falco.org\/docs\/getting-started\/falco-kubernetes-quickstart\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/setup\/operator\/\">https:\/\/falco.org\/docs\/setup\/operator\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/getting-started\/deployment\/\">https:\/\/falco.org\/docs\/getting-started\/deployment\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/github.com\/falcosecurity\/falco-operator\/blob\/main\/docs\/version-matrix.md\">https:\/\/github.com\/falcosecurity\/falco-operator\/blob\/main\/docs\/version-matrix.md<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 10. Rule Tuning and False Positives &#8211; 15 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Explain and reduce false positives without creating dangerous blind spots; add a targeted exception; understand rule enablement, alert noise, severity and dropped event counters.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The four outcomes of a detection rule<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Reality<\/th><th class=\"has-text-align-left\" data-align=\"left\">Falco alerts<\/th><th class=\"has-text-align-left\" data-align=\"left\">Falco stays silent<\/th><\/tr><\/thead><tbody><tr><td>Suspicious behavior happened<\/td><td>True positive<\/td><td><strong>False negative<\/strong><\/td><\/tr><tr><td>Legitimate behavior happened<\/td><td><strong>False positive<\/strong><\/td><td>True negative<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">A&nbsp;<strong>false positive<\/strong>&nbsp;could be a known maintenance script intentionally changing a protected configuration file. A&nbsp;<strong>false negative<\/strong>&nbsp;could be a malicious interpreter that an over-specific&nbsp;<code>bash<\/code>-only rule failed to catch. Neither outcome is fixed by indiscriminately disabling all noisy rules.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended tuning sequence<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Confirm the detection and its precise output:<\/strong>\u00a0rule, process, parent process, user, file, image and node.<\/li>\n\n\n\n<li><strong>Investigate the activity:<\/strong>\u00a0was it an approved operation, a routine job, or an unexplained anomaly?<\/li>\n\n\n\n<li><strong>Measure frequency and blast radius:<\/strong>\u00a0how many hosts\/containers and events per minute?<\/li>\n\n\n\n<li><strong>Write a narrow exception<\/strong>\u00a0identifying an approved actor\u00a0<em>and<\/em>\u00a0its permitted target\/action.<\/li>\n\n\n\n<li><strong>Retest positive and negative cases:<\/strong>\u00a0an approved actor should be excluded; a different actor must still alert.<\/li>\n\n\n\n<li><strong>Review and version the change:<\/strong>\u00a0record owner, reason, expiration\/revalidation and expected tests.<\/li>\n\n\n\n<li><strong>Monitor detection quality over time:<\/strong>\u00a0new application versions and changes in normal workloads can make old exceptions inaccurate.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Lab 10A: add an exception to our custom file-write rule<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Prerequisite:<\/strong>&nbsp;keep Chapter 7&#8217;s&nbsp;<code>90-falco-training.yaml<\/code>&nbsp;installed and active on the Ubuntu lab VM. This chapter creates a&nbsp;<strong>second<\/strong>&nbsp;rules file that overrides the rule defined earlier. The&nbsp;<code>95-<\/code>&nbsp;prefix sorts after&nbsp;<code>90-<\/code>; confirm your rules directory loads in filename order and appears after default rules.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Goal:<\/strong>&nbsp;exclude writes made to the mock file by the known&nbsp;<code>bash<\/code>&nbsp;training process, while still alerting when an alternative process writes to that same file.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Create a separate override file; do not edit default Falco rules<\/em>\nsudo tee \/etc\/falco\/rules.d\/95-falco-training-exceptions.yaml &gt; \/dev\/null &lt;&lt;'YAML'\n- rule: LAB Protected File Opened for Writing\n  exceptions:\n    - name: allowed_training_bash_writer\n      fields: &#91;proc.name, fd.name]\n      comps: &#91;=, =]\n      values:\n        - &#91;bash, \/tmp\/falco-lab-protected.txt]\n  override:\n    exceptions: append\nYAML\n\n<em># Validate the base rule AND its later exception override in one pass<\/em>\nsudo falco -V \/etc\/falco\/rules.d\/90-falco-training.yaml \\\n  -V \/etc\/falco\/rules.d\/95-falco-training-exceptions.yaml\n\n<em># Validate the configured full ruleset<\/em>\nsudo falco --dry-run -c \/etc\/falco\/falco.yaml\n\n<em># Reload via a controlled service restart on the lab host<\/em>\nsudo systemctl restart falco-modern-bpf.service\nsudo systemctl is-active falco-modern-bpf.service\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Why&nbsp;<code>override.exceptions: append<\/code>?<\/strong>&nbsp;The modern rule override format lets a later file add exception definitions or values without replacing the original entire rule. The legacy&nbsp;<code>append: true<\/code>&nbsp;syntax is deprecated; new policy should use&nbsp;<code>override<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Watch alerts in Terminal A:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo journalctl -fu falco-modern-bpf.service\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Run two test writers from Terminal B:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Known-good actor: explicitly execute Bash to perform the redirection.<\/em>\n<em># The specified (bash, mock-file) tuple should now be excluded.<\/em>\nbash -c 'printf \"trusted bash update\\n\" &gt;&gt; \/tmp\/falco-lab-protected.txt'\n\n<em># Different actor: Python opens the exact same mock file for append.<\/em>\n<em># An alert SHOULD still be produced if python3 is installed.<\/em>\npython3 -c \"open('\/tmp\/falco-lab-protected.txt', 'a').write('python change\\\\n')\"\n\n<em># Inspect the mock file itself<\/em>\ncat \/tmp\/falco-lab-protected.txt\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;<code>bash<\/code>&nbsp;+ this exact mock file no longer triggers&nbsp;<strong>this LAB rule<\/strong>;&nbsp;<code>python3<\/code>&nbsp;+ the same file still triggers&nbsp;<code>LAB Protected File Opened for Writing<\/code>. Other enabled Falco rules may independently alert, and that does not mean the exception failed. If both cases alert under the LAB rule, ensure the later file was loaded and the observed process names actually match. If both are silent, confirm the original rule is still loaded and producing detections.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Important distinction:<\/strong>&nbsp;This lab is intended to demonstrate a narrow two-field exception, not a general production recommendation to trust every&nbsp;<code>bash<\/code>&nbsp;process. A real exception should typically also consider workload identity, executable path, container image, namespace, parent identity or a restricted deployment\/maintenance window when available.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to enable and disable rules selectively<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A rule may include&nbsp;<code>enabled: false<\/code>&nbsp;in its definition or be disabled by a later rule override. Prefer documented Falco rule controls\/overrides over deleting upstream YAML. Example&nbsp;<strong>illustration only<\/strong>&nbsp;for a later override file:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>- rule: LAB Shell Started in Container\n  enabled: false\n  override:\n    enabled: replace\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">This disables the lab rule when supported by the installed version&#8217;s override semantics.&nbsp;<strong>Do not apply it during the positive\/negative labs<\/strong>, and do not globally disable Falco because one particular rule has too many alerts. In production, tune or restrict the specific rule(s), use mature\/stable rulesets deliberately, and test changes with a controlled rollout.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Falco&#8217;s upstream rules have different maturity levels: stable rules are commonly loaded by default; incubating or sandbox rules require an explicit decision to enable and tune. A noisy experiment should not silently redefine the detection baseline across all clusters.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Severity, alert suppression and production noise<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Increasing a rule&#8217;s severity does not make its logic more accurate.&nbsp;<strong>Priority<\/strong>&nbsp;supports incident routing and response, but the condition determines what is detected. Good severity policy considers impact, confidence and the identity of the workload. A critical asset running a shell unexpectedly can deserve more attention than a developer sandbox, even when the underlying syscall is identical.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Keep a tuning register:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Field<\/th><th class=\"has-text-align-left\" data-align=\"left\">Example<\/th><\/tr><\/thead><tbody><tr><td>Rule<\/td><td>LAB Shell Started in Container<\/td><\/tr><tr><td>False-positive cause<\/td><td>Approved diagnostic session<\/td><\/tr><tr><td>Workload<\/td><td>Development test container only<\/td><\/tr><tr><td>Proposed exception<\/td><td>Verified maintenance actor + image + command restrictions<\/td><\/tr><tr><td>Owner<\/td><td>Runtime security team<\/td><\/tr><tr><td>Review date<\/td><td>Next monthly detection review<\/td><\/tr><tr><td>Negative-control test<\/td><td>Unknown process still alerts<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Event drops: alert noise vs missing data<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Alert count is&nbsp;<strong>not<\/strong>&nbsp;the same thing as captured event count. A noisy rule can cause alert volume, while&nbsp;<strong>kernel event drops<\/strong>&nbsp;can indicate that the capture pipeline cannot keep up with load, creating blind spots.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Falco metrics can measure event rates, kernel-side drop counters, Falco output queue drops, resource utilization and rule counters. With Falco 0.45&#8217;s modern eBPF driver, additional auxiliary-map drop counters can help distinguish causes of loss.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Low-risk inspection in the lab (no config modifications):<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo falco --version\nsudo grep -n -A20 '^metrics:' \/etc\/falco\/falco.yaml | head -n 30\nsudo journalctl -u falco-modern-bpf.service --since '15 minutes ago' --no-pager | \\\n  grep -iE 'drop|buffer|backpressure|metric' | tail -n 25\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Production metrics planning (config fragment, not a full&nbsp;<code>falco.yaml<\/code>):<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>metrics:\n  enabled: true\n  interval: 1m\n  output_rule: true\n  rules_counters_enabled: true\n  resource_utilization_enabled: true\n  state_counters_enabled: true\n  kernel_event_counters_enabled: true\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Read Chapter 11 before applying monitoring changes. High event rates need observation and benchmark-driven tuning, not arbitrary bigger buffers. For example,&nbsp;<code>scap.n_drops<\/code>&nbsp;captures kernel-side event losses; changes should be studied alongside event rate, CPU, memory, alert queue, and application performance. Increasing ring-buffer capacity consumes memory and does not fix every kind of drop.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Undo the exception lab<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Remove only the experiment's override (the base two lab detections remain)<\/em>\nsudo rm -f \/etc\/falco\/rules.d\/95-falco-training-exceptions.yaml\nsudo falco --dry-run -c \/etc\/falco\/falco.yaml\nsudo systemctl restart falco-modern-bpf.service\nsudo systemctl is-active falco-modern-bpf.service\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Knowledge check<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0Is every alert a real security incident?\u00a0<strong>A:<\/strong>\u00a0No; legitimate activity can match a rule.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Why use process AND file path in an exception?\u00a0<strong>A:<\/strong>\u00a0To keep the exemption narrow and limit missed threats.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0What is the main risk of a broad exemption?\u00a0<strong>A:<\/strong>\u00a0False negatives\/security blind spots.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0What does a kernel event drop indicate?\u00a0<strong>A:<\/strong>\u00a0Some monitored events could not be delivered; it is not an ordinary low-severity alert or a mere cosmetic issue.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Completion checkpoint:<\/strong>&nbsp;You can add a narrowly scoped exception, prove that it suppresses only one allowed behavior and still catches a different actor, then roll it back safely.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/exceptions\/\">https:\/\/falco.org\/docs\/concepts\/rules\/exceptions\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/overriding\/\">https:\/\/falco.org\/docs\/concepts\/rules\/overriding\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/metrics\/\">https:\/\/falco.org\/docs\/concepts\/metrics\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/troubleshooting\/dropping\/\">https:\/\/falco.org\/docs\/troubleshooting\/dropping\/<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Chapter 11. Operations, Troubleshooting and Next Steps &#8211; 10 minutes<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Overview and learning outcomes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Core goal:<\/strong>&nbsp;Run practical health checks, understand&nbsp;<code>falcoctl<\/code>&nbsp;artifact management, diagnose the most common failures, and sketch a safe path from lab deployment to production operation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The five operational questions<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Is Falco running?<\/strong>\u00a0Is the process\/service active on every intended node?<\/li>\n\n\n\n<li><strong>Is it monitoring?<\/strong>\u00a0Has the syscall engine opened successfully and loaded the intended rules?<\/li>\n\n\n\n<li><strong>Can it detect?<\/strong>\u00a0Does a controlled positive test still create an alert?<\/li>\n\n\n\n<li><strong>Can it deliver?<\/strong>\u00a0Does the alert reach a retained\/logged\/forwarded destination?<\/li>\n\n\n\n<li><strong>Is it losing data?<\/strong>\u00a0What are the rates of dropped kernel events and output queue drops?<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">A working Falco&nbsp;<em>pod<\/em>&nbsp;alone is not proof of an effective deployment. Pods may be ready while rules are absent, enrichment is missing, integrations are misconfigured or selected events are being dropped.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Daily operational command runbook: Ubuntu host<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Software and host baseline<\/em>\nsudo falco --version\nuname -r\n\n<em># Daemon readiness and unit state<\/em>\nsudo systemctl is-active falco-modern-bpf.service\nsudo systemctl is-enabled falco-modern-bpf.service\n\n<em># Recent failure signatures and rule-loading messages<\/em>\nsudo journalctl -u falco-modern-bpf.service -n 120 --no-pager\n\n<em># Inspect active configuration; this does not require running a second sensor<\/em>\nsudo falco --dry-run -c \/etc\/falco\/falco.yaml\n\n<em># List the relevant services, including optional artifact updater<\/em>\nsystemctl list-units --all | grep -E 'falco|falcoctl'\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Daily operational command runbook: Kubernetes<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Validate context before every set of cluster commands<\/em>\nkubectl config current-context\n\n<em># Helm-based deployment checks<\/em>\nhelm list -n falco\nkubectl get daemonsets,pods -n falco -o wide\nkubectl get events -n falco --sort-by=.lastTimestamp | tail -n 25\nkubectl logs -n falco -l app.kubernetes.io\/name=falco \\\n  -c falco --since=10m --prefix=true\n\n<em># When using the Operator instead of the plain chart<\/em>\nkubectl get falco,plugins,rulesfiles,configs,components -n falco\nkubectl get pods -n falco-operator\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Expected:<\/strong>&nbsp;every intended node has a ready sensor, rules\/plugins are available, recent logs contain no persistent startup\/reload failures, and the output path works. If an operator resource reports a reconciliation failure, inspect its details with&nbsp;<code>kubectl describe<\/code>&nbsp;and operator controller logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">falcoctl &#8211; artifact and rules lifecycle<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>falcoctl<\/code>&nbsp;accompanies Falco and can manage rule artifacts, plugins and (where relevant) drivers. Falco packaging may install&nbsp;<code>falcoctl-artifact-follow.service<\/code>&nbsp;for compatible rule updates. Its job is different from Falco:&nbsp;<strong>falcoctl manages artifacts; Falco loads and evaluates rules<\/strong>. Do not confuse an up-to-date rule artifact with an up-to-date Falco binary or compatible kernel driver.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Confirm tool availability and inspect the installed command surface<\/em>\nfalcoctl --help\nfalcoctl artifact --help\nfalcoctl --version\n\n<em># Inspect related systemd units without changing their behavior<\/em>\nsystemctl list-unit-files | grep -E 'falco|falcoctl'\nsudo systemctl status falcoctl-artifact-follow.service --no-pager\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The&nbsp;<code>falcoctl-artifact-follow<\/code>&nbsp;unit might not be installed\/enabled in every deployment, especially container\/Operator setups; treat an absent unit as a packaging\/deployment difference, not immediate proof of failure. Use&nbsp;<code>falcoctl artifact search<\/code>&nbsp;or the configured artifact index to discover available rule versions. Before upgrading rules or plugins in production, confirm compatibility with the engine, review release notes, test local overrides, and roll out in staging.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Version-specific note:<\/strong>&nbsp;Falco 0.45.0 uses a driver API 11.0.0. Older kernel modules\/drivers are not necessarily compatible. Falco 0.45.0 also introduced incubating&nbsp;<code>\/reload<\/code>&nbsp;reporting and optional Unix-socket reload control; these are not needed for the beginner core and should not be treated as universally enabled public management endpoints.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Operational health metrics<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Falco&#8217;s native metrics are&nbsp;<strong>off by default<\/strong>&nbsp;and can be enabled in&nbsp;<code>falco.yaml<\/code>&nbsp;or appropriate Helm\/Operator configuration. The official documentation supports JSON metrics output and Prometheus exposure through an enabled webserver.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><em># Config fragment: merge into your verified configuration, not replace the entire file<\/em>\nmetrics:\n  enabled: true\n  interval: 1m\n  output_rule: true\n  kernel_event_counters_enabled: true\n  resource_utilization_enabled: true\n  rules_counters_enabled: true\n  state_counters_enabled: true\n\n<em># Enable HTTP metrics only when the listener is appropriately secured.<\/em>\nwebserver:\n  enabled: true\n  prometheus_metrics_enabled: true\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">When enabled,&nbsp;<code>\/metrics<\/code>&nbsp;shares the Falco health webserver port.&nbsp;<strong>Protect the endpoint&#8217;s network exposure<\/strong>&nbsp;through binding, networking rules and monitoring access controls; do not open a management\/metrics port to the internet. Observe Falco CPU\/memory, sensor availability, event throughput, kernel drops (<code>scap.n_drops<\/code>), output-queue drops and forwarding errors. For modern eBPF 0.45, also examine auxiliary-map counters when present. Always relate changes in metrics to cluster load and workload events.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting matrix<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Symptom<\/th><th class=\"has-text-align-left\" data-align=\"left\">Diagnose<\/th><th class=\"has-text-align-left\" data-align=\"left\">Likely cause<\/th><th class=\"has-text-align-left\" data-align=\"left\">Correction<\/th><th class=\"has-text-align-left\" data-align=\"left\">Verify<\/th><\/tr><\/thead><tbody><tr><td>Falco package unavailable<\/td><td><code>apt-cache policy falco<\/code><\/td><td>Missing apt source, DNS\/proxy or key issue<\/td><td>Correct signed official repo and refresh apt<\/td><td>Candidate appears<\/td><\/tr><tr><td><code>falco-modern-bpf<\/code>&nbsp;inactive<\/td><td><code>systemctl status<\/code>, journal<\/td><td>Service\/startup failure<\/td><td>Fix reported error, then restart in lab<\/td><td><code>is-active<\/code>&nbsp;returns&nbsp;<code>active<\/code><\/td><\/tr><tr><td>eBPF BTF\/ring buffer error<\/td><td><code>uname -r<\/code>,&nbsp;<code>\/sys\/kernel\/btf\/vmlinux<\/code>, journal<\/td><td>Kernel feature or VM limitations<\/td><td>Use a kernel\/VM with required features or supported alternate driver<\/td><td>Logs show source opened<\/td><\/tr><tr><td>Permission denied loading BPF<\/td><td>Journal, LSM policy and caps<\/td><td>Missing BPF privileges or host restrictions<\/td><td>Use documented privileges in authorized environment<\/td><td>Sensor initializes<\/td><\/tr><tr><td>Rule YAML fails validation<\/td><td><code>falco -V<\/code>&nbsp;and&nbsp;<code>--dry-run<\/code><\/td><td>Bad YAML, unknown field\/macro, wrong order<\/td><td>Fix exact parser error<\/td><td>Validation returns zero<\/td><\/tr><tr><td>No custom alert<\/td><td><code>rules_files<\/code>, startup logs, positive\/negative trigger<\/td><td>Rule not loaded, wrong source, shadowed\/mismatched condition<\/td><td>Correct path\/order\/condition, rerun controlled test<\/td><td>Expected rule name appears<\/td><\/tr><tr><td>No container name\/image<\/td><td>Container plugin and runtime socket setup<\/td><td>Missing plugin\/CRI access or metadata unavailable<\/td><td>Configure compatible metadata enrichment<\/td><td>Container context populated<\/td><\/tr><tr><td>No Kubernetes pod name<\/td><td>k8smeta\/collector setup<\/td><td>Missing pod metadata enrichment<\/td><td>Configure supported metadata plugin\/collector<\/td><td>Pod fields populated<\/td><\/tr><tr><td>Falco DaemonSet Pending<\/td><td><code>kubectl describe pod<\/code><\/td><td>Privileges, scheduling, image, node OS<\/td><td>Correct compatible node\/scheduling\/security constraints<\/td><td>Sensor pod Ready<\/td><\/tr><tr><td>Many false positives<\/td><td>Analyze alert samples<\/td><td>Overly broad logic<\/td><td>Narrow and test exception; record policy<\/td><td>Normal behavior excluded, malicious test alerts<\/td><\/tr><tr><td>Event-drop warnings<\/td><td>Metrics and event rate<\/td><td>Capture pipeline overloaded or specific driver issue<\/td><td>Profile and tune buffer\/rules with testing<\/td><td>Drops decrease under realistic load<\/td><\/tr><tr><td>Forwarder receives nothing<\/td><td>HTTP output and destination logs<\/td><td>Incorrect URL, firewall, auth or TLS<\/td><td>Repair and secure output path<\/td><td>Receiver sees controlled alert<\/td><\/tr><tr><td>Upgrade unexpectedly changes service<\/td><td>Package and driver release notes<\/td><td>Version-specific lifecycle changes<\/td><td>Pin\/test versions and driver selection<\/td><td>Post-upgrade sensor healthy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Production-ready deployment checklist<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Before operating Falco for a real business service, ensure:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>[ ] Every desired Linux node\/compute type can run an approved Falco driver and privileges.<\/li>\n\n\n\n<li>[ ] Base engine, chart\/operator, rules, plugin and driver versions are recorded and upgraded in a tested sequence.<\/li>\n\n\n\n<li>[ ] Custom rules are code-reviewed, version controlled, validated and tested with positive\/negative scenarios.<\/li>\n\n\n\n<li>[ ] Every critical rule has an owner, a defined severity and an investigation runbook.<\/li>\n\n\n\n<li>[ ] Rule exceptions are specific, reviewed and revisited after workload changes.<\/li>\n\n\n\n<li>[ ] Container and Kubernetes metadata are available as needed for incident triage.<\/li>\n\n\n\n<li>[ ] Alerts are routed over secured connections with secrets stored properly and field-level privacy reviewed.<\/li>\n\n\n\n<li>[ ] Sensor restarts, node coverage, dropped events and forwarding failures are monitored.<\/li>\n\n\n\n<li>[ ] An operator can reliably answer &#8220;what happened, where, who, and what should happen next?&#8221;<\/li>\n\n\n\n<li>[ ] Rollback and disaster recovery are rehearsed; Falco outages do not silently remove all detection coverage.<\/li>\n\n\n\n<li>[ ] Production response automation is separately designed and protected against accidental disruption.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Suggested next study milestones (after the 3-hour course)<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Intermediate project (half day):<\/strong>&nbsp;create a five-rule pack for a sample backend app: unexpected shell, protected config writes, unexpected process execution, suspicious network connection, and restricted Kubernetes namespace behavior. Test each with a positive and negative control and document alert triage.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Intermediate-to-advanced project (1-2 days):<\/strong>&nbsp;install Falco Operator on an approved test cluster, manage rules through declarative resources, add Falcosidekick to a secure receiver, enable metrics, test node replacements, and validate detection throughput\/noise during a sample application deployment.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Production-specialization project:<\/strong>&nbsp;define version pinning, GitOps integration, security controls, staging rollout, exceptions review, alert-to-incident correlation, system-level reliability SLOs, and incident response workflows. These require team agreement and environment-specific validation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Final knowledge check<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Q:<\/strong>\u00a0What proves sensor readiness?\u00a0<strong>A:<\/strong>\u00a0Active process, initialized event source, loaded rules, successful controlled alert and functioning delivery path.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0What is\u00a0<code>falcoctl<\/code>\u00a0for?\u00a0<strong>A:<\/strong>\u00a0Managing Falco ecosystem artifacts and drivers, not directly evaluating every syscall rule.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0What must you check when updating a kernel module?\u00a0<strong>A:<\/strong>\u00a0Compatibility with the kernel and Falco driver API, build\/signing and required privileges.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0Why monitor kernel event drops?\u00a0<strong>A:<\/strong>\u00a0Dropped events can undermine detection accuracy and alert completeness.<\/li>\n\n\n\n<li><strong>Q:<\/strong>\u00a0What can you now demonstrate at intermediate foundation level?\u00a0<strong>A:<\/strong>\u00a0Installing Falco, triggering events, writing\/tuning custom rules, inspecting outputs, deploying to a Linux-node cluster and performing basic operational checks.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Completion checkpoint:<\/strong>&nbsp;You can implement, verify and troubleshoot a lab Falco deployment and discuss production limitations without treating the demo setup as automatically production-ready.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Official references:<\/strong>&nbsp;<a href=\"https:\/\/falco.org\/docs\/troubleshooting\/start-up-error\/\">https:\/\/falco.org\/docs\/troubleshooting\/start-up-error\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/troubleshooting\/dropping\/\">https:\/\/falco.org\/docs\/troubleshooting\/dropping\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/metrics\/\">https:\/\/falco.org\/docs\/concepts\/metrics\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/default-custom\/\">https:\/\/falco.org\/docs\/concepts\/rules\/default-custom\/<\/a>&nbsp;;&nbsp;<a href=\"https:\/\/falco.org\/blog\/falco-0-45-0\/\">https:\/\/falco.org\/blog\/falco-0-45-0\/<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Consolidated quick reference<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Commands to memorize<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Goal<\/th><th class=\"has-text-align-left\" data-align=\"left\">Command (run on an authorized Linux host unless noted)<\/th><\/tr><\/thead><tbody><tr><td>Check binary version<\/td><td><code>sudo falco --version<\/code><\/td><\/tr><tr><td>Check driver service<\/td><td><code>sudo systemctl status falco-modern-bpf.service --no-pager<\/code><\/td><\/tr><tr><td>Follow host alerts<\/td><td><code>sudo journalctl -fu falco-modern-bpf.service<\/code><\/td><\/tr><tr><td>List rules<\/td><td><code>sudo falco -L<\/code><\/td><\/tr><tr><td>List fields<\/td><td><code>sudo falco --list=syscall -N<\/code><\/td><\/tr><tr><td>List event types<\/td><td><code>sudo falco --list-events<\/code><\/td><\/tr><tr><td>Validate rules<\/td><td><code>sudo falco -V \/path\/to\/rules.yaml<\/code><\/td><\/tr><tr><td>Validate configuration<\/td><td><code>sudo falco --dry-run -c \/etc\/falco\/falco.yaml<\/code><\/td><\/tr><tr><td>Restart lab service<\/td><td><code>sudo systemctl restart falco-modern-bpf.service<\/code><\/td><\/tr><tr><td>Examine falcoctl<\/td><td><code>falcoctl artifact --help<\/code><\/td><\/tr><tr><td>Add Helm repo<\/td><td><code>helm repo add falcosecurity https:\/\/falcosecurity.github.io\/charts<\/code><\/td><\/tr><tr><td>View Kubernetes sensors<\/td><td><code>kubectl get pods,ds -n falco -o wide<\/code><\/td><\/tr><tr><td>View Kubernetes alerts<\/td><td><code>kubectl logs -n falco -l app.kubernetes.io\/name=falco -c falco --since=10m<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">How to decide whether a rule is good enough<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A minimum acceptable custom rule should include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An explicit security objective and expected malicious behavior.<\/li>\n\n\n\n<li>A reasonably bounded positive event expression, normally including\u00a0<code>evt.type<\/code>.<\/li>\n\n\n\n<li>Useful but privacy-conscious output fields for investigation.<\/li>\n\n\n\n<li>A suitable priority and searchable tags.<\/li>\n\n\n\n<li>A\u00a0<strong>positive test<\/strong>\u00a0that proves the behavior is detected.<\/li>\n\n\n\n<li>A\u00a0<strong>negative test<\/strong>\u00a0that proves an allowed behavior is not mistaken for that behavior.<\/li>\n\n\n\n<li>A documented false-positive boundary and an owner for future tuning.<\/li>\n\n\n\n<li>A compatible deployment\/rollback method.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Course-wide self-assessment rubric<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Score each competency&nbsp;<strong>0<\/strong>&nbsp;(cannot explain),&nbsp;<strong>1<\/strong>&nbsp;(can explain),&nbsp;<strong>2<\/strong>&nbsp;(can demonstrate with guidance),&nbsp;<strong>3<\/strong>&nbsp;(can demonstrate independently):<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Competency<\/th><th class=\"has-text-align-left\" data-align=\"left\">Expected result<\/th><\/tr><\/thead><tbody><tr><td>Explain purpose<\/td><td>Contrast Falco, scanning, policy controls and SIEM<\/td><\/tr><tr><td>Understand kernel evidence<\/td><td>Identify process, syscall, file and container context<\/td><\/tr><tr><td>Explain architecture<\/td><td>Modern eBPF\/driver -&gt; libs -&gt; rules -&gt; alert<\/td><\/tr><tr><td>Host install<\/td><td>Start Falco on a supported Ubuntu VM<\/td><\/tr><tr><td>Trigger events<\/td><td>Detect sensitive-file access and inspect an alert<\/td><\/tr><tr><td>Read rules<\/td><td>Explain rule, macro, list, conditions and output fields<\/td><\/tr><tr><td>Author rules<\/td><td>Write and validate two original detections<\/td><\/tr><tr><td>Forward output<\/td><td>Explain JSON output and Falcosidekick<\/td><\/tr><tr><td>Kubernetes<\/td><td>Deploy\/read a per-node sensor and trigger a pod event<\/td><\/tr><tr><td>Tune rules<\/td><td>Add one narrow exception while preserving another detection<\/td><\/tr><tr><td>Operate<\/td><td>Find health, coverage, rule, plugin and event-drop problems<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Passing target for the three-hour foundation:<\/strong>&nbsp;level 2 or above in at least 9 of the 11 competencies. Level 3 in rules, tuning and operations usually requires additional sessions.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">Verified references and version notes<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">The following are official project\/vendor resources relevant to the precise claims in this guide, accessed\/checked for the&nbsp;<strong>11 October 2026<\/strong>&nbsp;reference baseline:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><a href=\"https:\/\/falco.org\/blog\/falco-0-45-0\/\">Falco 0.45.0 release announcement<\/a>\u00a0&#8211; 21 September 2026; driver API 11.0.0; bundled falcoctl 0.14.2; falco-rules 5.2.0; 0.45 changes.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/getting-started\/falco-linux-quickstart\/\">Falco Linux quickstart<\/a>\u00a0&#8211; official apt instructions, Lima example, modern eBPF and\u00a0<code>\/etc\/shadow<\/code>\u00a0demo.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/getting-started\/falco-kubernetes-quickstart\/\">Falco Kubernetes quickstart<\/a>\u00a0&#8211; Linux-node cluster, Helm commands, demo pod event.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/setup\/operator\/\">Falco Operator deployment<\/a>\u00a0&#8211; current recommended Kubernetes management model; CRDs; install\/cleanup ordering and Kubernetes prerequisites.<\/li>\n\n\n\n<li><a href=\"https:\/\/github.com\/falcosecurity\/falco-operator\/blob\/main\/docs\/version-matrix.md\">Falco Operator version matrix<\/a>\u00a0&#8211; validate the default Falco image deployed by an operator release.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/concepts\/event-sources\/kernel\/\">Falco kernel event sources and modern eBPF<\/a>\u00a0&#8211; supported drivers and feature prerequisites.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/concepts\/event-sources\/kernel\/architecture\/\">Kernel event architecture<\/a>\u00a0&#8211; driver-to-userspace event pipeline.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/\">Falco rules syntax<\/a>\u00a0and\u00a0<a href=\"https:\/\/falco.org\/docs\/rules\/supported-fields\/\">supported fields<\/a>\u00a0&#8211; conditions, lists, macros and rule attributes.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/style-guide\/\">Falco rules style guide<\/a>\u00a0&#8211; efficient rule construction, positive event selection, output conventions.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/exceptions\/\">Falco rule exceptions<\/a>\u00a0and\u00a0<a href=\"https:\/\/falco.org\/docs\/concepts\/rules\/overriding\/\">overriding<\/a>\u00a0&#8211; tuning and current\u00a0<code>override<\/code>\u00a0syntax (old\u00a0<code>append: true<\/code>\u00a0is deprecated).<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/reference\/daemon\/cli-arguments\/\">Falco CLI options<\/a>\u00a0&#8211;\u00a0<code>-V<\/code>,\u00a0<code>--dry-run<\/code>,\u00a0<code>-r<\/code>,\u00a0<code>--list<\/code>\u00a0and logging options.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/concepts\/outputs\/\">Outputs and Falcosidekick<\/a>\u00a0&#8211; standard channels, JSON, HTTP forwarding and ecosystem integrations.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/concepts\/metrics\/\">Falco metrics<\/a>\u00a0&#8211; operational counters and optional Prometheus endpoint.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/docs\/troubleshooting\/dropping\/\">Falco event-drop troubleshooting<\/a>\u00a0&#8211; buffers, dropped syscall events and modern eBPF 0.45 counters.<\/li>\n\n\n\n<li><a href=\"https:\/\/canonical.com\/multipass\/install\/\">Canonical Multipass installation<\/a>\u00a0&#8211; Windows virtual-machine path.<\/li>\n\n\n\n<li><a href=\"https:\/\/falco.org\/blog\/falco-0-44-0\/\">Falco 0.44.0 breaking changes<\/a>\u00a0&#8211; removed legacy eBPF, gVisor engine and gRPC output.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Final caveat:<\/strong>&nbsp;This training document supplies copy-ready commands and complete core YAML examples, but its sample workloads were not executed in a real Linux kernel\/Kubernetes environment during authoring. Running them yourself and validating actual results against the installed Falco\/driver\/rules versions is part of the learning process. In production, prefer vendor-tested deployment choices, staged rollouts and an explicit rollback plan.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Last documentation verification:&nbsp;11 October 2026Reference Falco release:&nbsp;0.45.0 (released 21 September 2026)Reference host lab:&nbsp;Ubuntu Server 24.04 LTS, Linux kernel with modern eBPF supportReference companion versions in Falco 0.45.0:&nbsp;falcoctl&#8230; <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1201","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1201","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1201"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1201\/revisions"}],"predecessor-version":[{"id":1202,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1201\/revisions\/1202"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1201"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1201"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1201"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}