Open-Source Security Tools
Falco: Runtime Threat Detection for Containers
Falco is the CNCF runtime security tool that watches system calls; rules describe behaviors that should never happen (a shell spawned in nginx, someone reading /etc/shadow, a container mounting the host filesystem), and Falco alerts the moment they do. It is the counterpart to image scanning: Trivy-class tools catch known vulnerabilities before deploy, Falco catches misbehavior while running.
Key points
- The data source is syscalls: a kernel module or modern eBPF driver feeds event streams that rules match against process/container context (image, namespace, user, syscall args), including container-aware fields like Kubernetes deployment metadata; this syscall-level lens sees what log-based detection misses.
- Default rules cover the classic container-escape classes: privileged container starts, sensitive file reads, reverse shells, unexpected network tools inside containers, write below mounts, and known container-runtime sibling spawning; the default set is a starting baseline meant to be tuned per estate.
- Rules are YAML and system calls, not signatures: no CVE feeds to update; instead behavior policy like 'spawned_process and proc.name in (shellkit binaries)' expresses the estate's expectations; the tuning story is class-level (write v read binaries) rather than per signature.
- Output is plugin-based: stdout, syslog, Slack, webhook to the orchestrator, and key modern integrations (Falco Talon-class automated response); most estates point alerts at the same SIEM as Wazuh (our dedicated article) so runtime and endpoint alerts correlate.
- Deployment shape matches the estate: daemonset on Kubernetes (eBPF driver on modern kernels), host-based for standalone Docker hosts; resource footprint is modest but shakes on 10G-node-class kernels, which matters because eBPF probes tie closely to kernel versions and distros.
- The honest positioning in our security-tools set: Falco detects misconduct, it does not prevent it; pair it with image scanning (Trivy), admission policies (Kubernetes security context/orchestration tooling), and network controls; a breach caught at 3 a.m. is worth more than a scan report nobody read.
Field note
Falco's first catch on a client cluster: a debugging image that shipped with a shell, and someone used it in production out of habit. No CVE, no scanner hit, pure behavior. The rule that fired was a default we had meant to tune. Defaults sometimes earn their keep loudly.
Frequently asked questions
Falco vs a commercial CNDR product?
Falco covers the syscall-detection core as open source with a rules format owned by the community; commercial tools add UI, ML anomaly models, and managed response workflows, and many estates run Falco alongside for the syscall layer.
What does Falco catch that scanners miss?
Runtime behavior: a compromised credential used to spawn a shell, a container reading secrets it should not, the pivot from the web tier into a Kubernetes cluster; scanners inspect what shipped, Falco watches what happens.
Is eBPF mandatory?
The eBPF driver is the modern default and avoids kernel-module maintenance; a legacy kernel module exists for older kernels, and the syscall source plugin extends Falco beyond Linux hosts.
How noisy are the default rules?
Noisy on estates with unusual tooling, especially during deploys; expect a real tuning cycle (per-namespace exception rules) over the first weeks before alerts become operably cold rather than automatic background noise.
How Kinetikatech helps with open-source security tools
Honestly, most teams come to us after trying it themselves first: The testing toolbox professionals actually keep loaded: scanners, sniffers, crackers, and web proxies explained the way they are used on real engagements — commands, flags, outputs, and where each one sits in a methodology. Our Penetration Testing and Linux Server Security service exists so you don't have to learn open-source security tools the hard way, we handle the setup, the watching, and the 3 a.m. surprises.